On Wed, 24 Jan 2007, william(at)elan.net wrote:
With permission, I'll repost most of Stuart's comments back to the
list where original post came from, my comments below are for
SPF-discuss itself.
Permission granted.
A lot of recipients are unable (for various reasons) to setup
per-receipent whitelisting or per-receipient SPF checking
(i.e. site does SPF checking for all incoming email for all users).
My view is that they probably should not forward to account
like this, but lets be clear - SPF does break forwarding and
nobody is disputing it, the question is more often if its a
good thing or not.
Actually, reputation breaks forwarding. Without SPF, your IP
gets blacklisted. With SPF+SRS, your domain can get blacklisted
instead.
Ideally, a forwarder would have an SPF record for their domain, and
their recipients would list that domain in trusted forwarders.
Listing all forwarders in central repository is against practice of
decentralization of email system. Wayne who set it up can correct
me but my understanding is that its always been only a temporary
thing and only for few largest and most used forwarders.
Sorry for not beaing clear. I was *not* talking about trusted-forwarders.org.
I was talking about some configuration at the recipient end where
they list their forwarders by domain. In pymilter, that config
option is called "trusted_forwarders".
SRS is actually more useful as a variation on BATV to reject bounces of
your forged domain.
Lets call it appropriately as its BATV that came as variation of
SES which came out of work on SRS. For SPF Community it would be
good to release their own documents/text-draft that describes
SES close to its original concept (without RFC2822 additions
and only done as encrypted MAIL FROM with optional dns server
to answer if the crypted id is ok or not) and work on the
implimentations to be listed on the website. Same goes for SRS
as there is no good (recent/updated) text standard either.
The same MTA is going to be signing internal domains, and rewriting
forwarded domains. It is simpler to have the same library do both.
The original SES (supported by pysrs) does not work well with grey
listing and sendmail. The signature changes every time. (Same with the
rfc2822 flavor of SES.) On getting a 4xx error, the MTA has to remember
what the MAIL FROM was changed to, so it won't be different when it
retries. This is difficult or tricky to do in sendmail. It can't be
handled by the milter interface. The CF code would have to store the
modified MAIL FROM in the queue file - not a standard procedure.
With SRS signatures, they change only every day. So greylisting
and other 4xx errors work fine.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735