Alex van den Bogaerdt writes:
If someone wants to forward messages, by all means do so but do take
responsibility for any errors when _you_ (not you Seth, the forwarder)
run into problems. You cause a problem, you solve it, so you need to
be informed (by receiving the stuck message).
If you don't want to be informed about delivery problems, don't use
your address as the MAILFROM when *you* send the mail. If you do, you
are declaring that you want DSNs sent to your address - that you want
to be notified if your mail doesn't reach the intended recipient.
RFCs 821 and 2821 have an implicit assumption that the source identity
and DSN address are the same. There is a move afoot to formally
separate them, but the DSN address will still be the SMTP MAILFROM.
In the words of draft-crocker-email-arch-04:
RFC2821.MailFrom
Set by: Source
This is an end-to-end string that specifies an email address for
receiving return control information, such as "bounces". The name
of this field is misleading, because it is not required to specify
either the author or the agent responsible for submitting the
message. Rather, the agent responsible for submission specifies
the RFC2821.MailFrom address. Ultimately the simple basis for
deciding what address needs to be in the RFC2821.MailFrom is to
determine what address needs to be informed about transmission-
level problems (and, possibly, successes.)
If you submit mail, you are the "agent responsible for submission",
and you get to specify the end-to-end RFC2821.MailFrom DSN address.
"End-to-end" means a forwarder is supposed to preserve this.[1]
Yes, the words above are from a draft, not yet a full-fledged RFC
(unless it has recently beome one without my noticing). However, it's
a draft by the same Dave Crocker who wrote RFC822 23 years ago. What
he says carries a lot of weight among email people.
[1] Aside to Frank: I believe this "end-to-end" notion is implicit in
existing RFCs, something like construction of reverse paths by moving
elements from forward path to reverse path => reverse (and forward)
source routes being collapsed to direct connection => one-hop
MAILFROMs => end-to-end MAILFROMs ... => SRS reintroducing indirect
reverse paths. That last step is the origin of my comment that I feel
my using SRS violates RFCs. I use it because only the letter of the
RFCs is violated, not the spirit - meaning DSNs still make it back to
the original MAILFROM.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com
-------
Sender Policy Framework: http://spf.pobox.com/
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com