I have watched this list for a week or so, and posted SPF records for
Arnold.com, but I am deeply concerned about the way this discussion is
headed.
The mail from address in the (E)SMTP dialogue, sometimes called the
envelope sender, but better described as the envelope return address,
has a defined meaning: It is the address to which delivery status
notifications are to be sent (or <> if DSNs should not be sent). Any
attempt to redefine the meaning of the envelope return address as a
sender, where it conflicts with the current meaning, is doomed. User
agents and MTA will simply not be rewritten to use the new meaning, no
matter how well-intentioned.
I'm no expert on this matter, but it seems to me that you would have
much better luck standardizing and popularizing an SMTP service
extension (SMTP Service Extensions, RFC 1869) for SPF. MTAs could pass
along an authenticated sending domain (or mail address) in the SMTP
dialogue, where it could be checked before the data phase against any
SPF records in the DNS. For example, my MTAs could run a forwarding
service and when sending as clients (C), look for the support from the
new ESMTP verb "responsible sender", RESSEN. When connecting to server
(S) MTAs that advertise it, the dialogue might go something like this:
S: 220 smtp.example.com ESMTP server ready
C: EHLO mail.Arnold.com
S: 250-mail.Arnold.com
S: 250 RESSEN
C: RESSEN Abuse(_at_)Arnold(_dot_)com
S: 235 Responsible sender accepted
A spammer connecting to the same server MTA and claiming to be my MTA
might get a different result:
S: 220 smtp.example.com ESMTP server ready
C: EHLO mail.Arnold.com
S: 250-mail.Arnold.com
S: 250 RESSEN
C: RESSEN Abuse(_at_)Arnold(_dot_)com
S: 530 5.7.1 65.248.58.230 is not an SPF-registered MX for Arnold.com
A legitimate client or a spammer with no SPF support might get yet a
different result:
S: 220 smtp.example.com ESMTP server ready
C: EHLO mail.Arnold.com
S: 250-mail.Arnold.com
S: 250 RESSEN
C: MAIL FROM ...
...
C: DATA
S: 4xx Please use RESSEN (RFC xxx). Mail without it will be
accepted on the third try.
(These examples indicate how to incent senders to use software that
supports the new verb.)
I have only about 10 minutes of thought invested in this RESSEN
mechanism, which I just made up. It's probably not the right way to go.
My point is to illustrate how to do SPF with an SMTP service extension,
while supporting relaying and being backwards compatible with standards
that are not going to change.
So forget about changing the meaning of MAIL FROM. It won't happen.
Folks, especially those doing (legitimate or spam) bulk mailing for
others, will continue to use it exactly the way it was intended, to
control the destination of delivery status notifications. It can be
completely independent of the sender.
Regards,
"Steve" Stephen L. Arnold, Ph.D., President, Arnold Consulting, Inc.
Address 2530 Targhee Street, Madison, Wisconsin 53711-5491 U.S.A.
Telephone +1 608 278 7700 Facsimile +1 608 278 7701
Internet Stephen(_dot_)L(_dot_)Arnold(_at_)Arnold(_dot_)com
http://WWW.Arnold.com
Arnold® is a registered trademark and service mark of Arnold Consulting, Inc.
-------
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_)½§Åv¼ð¦ç?2b¥yÈbox(_dot_)com