Meng Weng Wong wrote:
The New SPF adds a "Responsible From" parameter:
As a sneak preview, suppose your email had:
From: <mengwong(_at_)pobox(_dot_)com>
Sender: <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
When that message is sent over SMTP, in The New SPF, mail would show up as:
MAIL FROM:<mengwong(_at_)pobox(_dot_)com> SIZE=1000
RFROM=<mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
[Snippage]
Unfortunately, today, if you give RFROM to an SMTP server, that input
produces
555 Unsupported option: RFROM=<mengwong(_at_)pobox(_dot_)com>
So ESMTP servers that grok RFROM would have to advertise RFROM
support in the EHLO response.
This is something that we couldn't have contemplated six months ago,
but together, today, SPF and Caller-ID have enough traction that the
MTA community might actually go along with a new extensioin.
Ahem. Might.
This is a wonderful solution to the "forwarding problem". I like
the concept. I find myself skeptical wrt. deployability however.
Perhaps I am unreasonable in thinking that forwarders should
take responsibilty for dealing with the problems that forwarding
causes. SPF-1 is a perfectly reasonable and well considered
solution to the sender verification problem as it sits, and the
fact that it breaks the hack of propogating "MAIL FROM" ahead
instead of setting it to the forwarding account so that the hack
of bouncing instead of rejecting messages will work doesn't bother
me in the least.
I consider maintaining a DB structured as follows:
"Forwarding_account messageID received_from"
a perfectly reasonable way to handle the path reversal that
needs to be done to handle bounces. Rejects should be handled
live if possible. The database can even have a ridiculously short
expire to keep it from growing too large.
This is _simpler_ than SES, SRS, RFROM, and many other "solutions"
to the problem. It also requires _NOTHING_ from anyone other than
the forwarding host. Why make a Federal case out of something
that can be fixed with a screwdriver?
--
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com http://www.vocalabs.com/
(952)941-6580x203