I don't think SPF is attempting to redefine the meaning of the
Return-Path. If you read carefully:
http://spf.pobox.com/srs.html
you will see that this only applies to email forwarding servers. You
don't even need to bother with the Sender Rewriting Scheme if you your
emails are handed over directly to your final destination mail-server.
Even on mail-forwarding servers, the meaning of this header is still
present: This is the address to return the email, in case there is
any trouble.
SRS is ugly, but standards-compliant. SPF doesn't block mail, of
course. However there is a proposal on this list to require the
envelope return address in the SMTP dialogue to match the Sender header
address in order to get forwarded mail around SPF-based blocking
schemes. It is this requirement to which I'm objecting.
The problem here lies in the fact that the autentication is done based
on the MAIL-FROM in the SMTP-dialogue. The domain of this is checked
against the IP of the mail-server trying to send the mail using the
SPF-techniques.
Now imagine your mail-server for @my-domain.com sends email to a
@mail-forwarder.com address, which then forwards your email to some final
destination @final-destination.com. If the MAIL FROM is kept as
@my-domain.com after being forwarded by mail-forwarder.com mail-server,
the recipient would now know that this email has been forwarded (you
can't trust older Received-lines...) so if SPF is active, it will just
reject the email, since the mail-forwarder.com mail-servers are not
allowed to send emails using the my-domain.com.
So we rewrite the address so it seems to come from mail-forwarder.com's
domain. But we still want to be able to return the mail to the sender
in case there is any problem (because that's one of the meanings of this
MAIL FROM envelope header anyway), so the rewritten address has to
contain some kind of information about the original sender. The proposed
scheme at the link I mentioned earlier is one way to accomplish this.
I'm concerned partly because the changing of an envelope return address
set by the sender seems like overstepping the rights of a relaying MTA.
The sender might want the notification from the ultimate destination if
the mail can't be delivered. Presumably this would be covered in the
service agreement for the forwarding service (e.g., the charter of a
mailing list).
The rewriting and the translation back has to be handled by the
mail FORWARDING server only, and no place else.
I'm suggesting that SPF be modified to compare the client IP address to
an address in a new SMTP service extension designed for that purpose,
*if* *present*, and otherwise against the envelope return address.
Then forwarded MTA would not have to encode the original sender a new
envelope return address or record it in a database, and envelope return
addresses would not need to be ugly.
Your ideas are interesting, but they have to be implemented in much more
places (mail client? all MTA?), so I think the chosen rewriting technique
is more pragmatic.
Only server-MTAs that want to implement SPF blocking but permit
forwarding would need to accept and interpret the new service extension.
These are the same as the MTAs that must know about SPF in the current
draft.
Only forwarding client-MTAs that don't want to have mail blocked or
delayed would need to need to offer it. These are the same MTAs that
that would need to implement SRS.
I'm suggesting that in a world with forwarding, SPF would consist of a
DNS enhancement and an SMTP service extension. In the current proposal,
SPF is only a DNS enhancement, and SRS is a separate requirement to
support forwarding. Except for the head start that SRS has over any
SMTP service extension, the ESMTP route does not seem to me to be more
difficult to implement.
ESMTP is now 12 years old. (It was introduced in 1992 with MIME.) It
has been a spectacular success. Offering a responsible sender address
during the SMTP dialogue seems to require much less effort than tracking
the original recipient address for the DSN service extension, which is
now widely implemented.
(I say "seems" a lot above because I'm new to this discussion.) Keep
thinking and discussing!
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