I'm going to speak in terms of figure 5, becuase figure 3 seems pretty abstract.
+------+
...............+ oMUA |<------------------------------+
. +--+---+ |
. | {smtp, submission |
. V |
. +------+ |
. | MSA |<--------------------+ |
. +--+---+ | |
. | {smtp | |
. V | |
. +------+ /+===+===+\ |
. | MTA | || dsn || |
/+==========+\ +--+---+ \+=======+/ |
|| MESSAGE || . {smtp ^ ^ |
||----------|| . | | |
|| Envelope || . | | |
|| SMTP || V | | |
|| RFC2822 || +------+ | | /+==+==+\
|| Content || | MTA +-------------------+ | || mdn ||
|| RFC2822 || +--+---+ | \+=====+/
|| MIME || | {local, smtp, lmtp | |
\+==========+/ V | |
. +------+ | |
. | +-----------------------+ |
. | MDA | |
. | |<--------------------+ |
. +-+--+-+ | |
. local} | | | |
. V | | |
. +------+ | /+===+===+\ |
. | MS-1 | | || sieve || |
. +-+--+-+ | \+=======+/ |
. | | | {pop, imap ^ |
. | V V | |
. | +------+ | |
. | | MS-2 | | |
. | +--+---+ | |
. | | {pop, imap, local | |
. V V | |
. +------+ | |
...........>| rMUA +------------------------+---------+
+------+
I'm going to lay down some ground rules for my hypothetical environment. (MTA
also refers to MSAs and MDAs.)
1. If a received email does not contain a return-path header, an MTA should
create a return-path header based on the envelope sender.
2. If a received email does contain a return-path header, an MTA should not
alter it or create any additional return-path headers.
3. MTAs should send DSNs to the recipient specified in the return-path header.
4. Forwarders should use the local mailbox as the envelope sender on forwarded
email.
Using the above logic, spammers could forge return-path headers all day long
from their MUAs/MSAs and it will cause DSN backscatter, but DSN backscatter is
not spam. Spammers already cause plenty on DSN backscatter in this manner, but
I don't think spammers would be motivated to intentionally fill your inbox with
their spam as DSN-attached files. If DSN-attached SPAM passed SPF at the hop
from the MSA, then the domain is identifiable.
Forwarders will pass SPF at MTAs/MDAs. DSNs will go back to the oMUA. It would
be transparent to the rMUA.
I know you tried to explain a loophole in terms of figure three, but I didn't
really understand it. If you could explain it in terms of figure five, I would
appreciate it.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
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