Hello!
On Tue, Dec 07, 2004 at 11:34:27PM +0100, Frank Ellermann wrote:
Hannah Schroeter wrote:
[64 characters for id-left ?]
RFC 2821, section 4.5.3.1
Yes, thanks, it has some rather obscure side-effects on things
like the %{l} in SPF-per-user policies when longer local parts
are silently accepted or created.
This is not so much a problem. After SRS, the domain is the domain of
the SRS forwarder instead of the original sender.
So if we rewrite
foo(_at_)bar(_dot_)baz
(where bar.baz's SPF record has something with %{l} inside)
to
SRS0=alsdkj=ab=bar(_dot_)baz=foo(_at_)srs(_dot_)schlund(_dot_)de
this will be no problem, as srs.schlund.de either has no SPF record,
or a simple one just listing the IPs of our outgoing SMTP pool.
I'd guess the situation will be similar for other SRS forwarders?
And if a forwarder co-locates SRS envelopes and other envelopes to the
same domain (which we do *not* plan to do in this company, we'll use a
separate domain name for SRS only), then a record could perhaps look
like
v=spf1 a:1.2.3.4 a:5.6.7.8 exists:%{l}.may-be-nomadic.domain -all
If we define that too long %{l} would lead to non-match (as that can't
exist as a domain name anyway), we'd still have the desired effect: SRS
addresses (which could be longer than 64 bytes) aren't created by
nomadic users, *they* create only their normal authorized local parts.
The pragmatical stand of our company *seems* to be now, we'll
implement SRS some time
Always or only when needed (SPF-protected sender) ?
Always (except if the envelope from is local, i.e. we're a MX for the
envelope sender's domain). Implementing SPF itself seems not to be a
high priority here. One point is the complexity and the interaction
between parsing and DNS queries (i.e. new DNS queries can result from
parsing an SPF record). IIRC existing SPF implementations don't allow
the resolver to be "pluggable" (i.e. a DNS callback to be used instead
of some given default resolver). Or am I wrong?
Maybe we
need a warning in the SPF spec. about %{l} in sender policies
of "SRS-forwarded domains".
Will be no problem for us. We'll use a separate domain for SRS addresses
we generate, and we'll either not publish SPF at all, or very simple
records, for them.
If there are receiver MTAs that enforce those 64 characters,
we'll just assume that they're also exotic and they will not
check SPF, so we will just disable SRS
Then you might find an LHS-tolerant MX doing SPF forwarding to
an LHS-paranoid MDA. You have enough domains for all possible
problems. Let's hope that they upgrade their MDA in this case.
Yeah. OTOH, the simple problem host list solution seems to work fine for
GMX's sender rewriting scheme, which is one data point in favour of this
simple solution. Another data point is that someone here wrote that he
hasn't found any problems with local parts > 64 characters yet.
Bye, Frank
Kind regards,
Hannah.