In <20041208162513(_dot_)GA28720(_at_)schlund(_dot_)de> Hannah Schroeter
<hannah(_at_)schlund(_dot_)de> writes:
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?
Yes
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.
If you need to create longer SRS localparts and also use %{l}, I would
recommend using %{l=}, or possibly even %{lr=}
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?
I'm not certain I understand what you are saying, but libspf2 does
allow different resolvers to be used pretty easily.
-wayne