On the subject of remailer services: SPF does require that forwarders
now rewrite the envelope sender. This is the single biggest
inconvenience and the first thing I would change about SPF if I could.
But even if SPF the standard went away, things would still be headed in
that direction, because SPF the concept is something people seem to
want. Over the last year or so people have been independently coming up
with the idea and writing standards drafts and starting implementations
before discovering SPF.
Example 1: For the last year or so we've been seeing ISPs reject mail
with the error "Sorry, you don't look like Yahoo". They're doing
pseudo-SPF. Initially we wrote to them saying "STOP IT, YOU'RE BREAKING
THINGS" and they added us to their whitelist. But more and more people
are doing this. Eventually we recognized that there was no point
fighting change, and asking everybody to whitelist us just wouldn't
scale. Forwarders, being in the middle, get squeezed from both ends.
It's something we all have to deal with sooner or later.
Example 2: AOL publishes its range of outbound mail servers:
http://postmaster.info.aol.com/info/servers.html
ISPs have taken that list and hardcoded it into their MTAs. If you get
an error "forged aol.com sender address not coming from AOL network",
that's why. This is something that forwarding providers have to deal
with anyway.
These issues didn't exist ten years ago, but they do now because of
spam. Change is a part of life. Forwarding providers are the first to
be affected, because they have an obligation to their userbase. For our
part, all of our users can turn on incoming SPF checks at varying
degrees of severity --- reject or discard or tag --- and if they turn on
SPF then SRS rewriting will automatically happen for mail coming from an
SPF-enabled domain. After the beta testers have a go at it, we'll
probably make SPF tagging plus SRS rewriting a sitewide default.
I am committed to helping forwarding providers find solutions; to date,
I have written to ACM, IEEE, AlumniConnections, and others with an offer
to help. I pointed them at http://spf.pobox.com/srs.html. We also
developed Mail::SRS and published it opensource and are looking for ways
to make that talk to MTAs. If Sendmail and Postfix and Exim and Qmail
all get SRS capability, the average user might not even have to do
anything more than upgrade their MTA, and existing forwards would just
do the right thing. That maximizes backward-compatibility. I would
like to see the MTA community work with us on this.
The important thing is that the mail gets through. If, in the worst
case, a receiving MTA rejects a forwarded message, the bounce message
will show the final recipient's email address, and the sender can resend
to that directly. This is inelegant but it is what the average end user
cares about.
I am trying to get SRS patches written for Postfix. If you can help
with this, please join spf-devel.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡