ietf-mxcomp
[Top] [All Lists]

Re: Will Accepting SUBMITTER Get You Blacklisted?

2004-08-09 04:34:54

On Sat, 7 Aug 2004, Michael R. Brumm wrote:

Here's a little problem I see with implementing SUBMITTER on an MTA...
let me know if I'm wrong on anything.

First, let's assume a domain "allows-submitter.com", who has MTAs which
allow SUBMITTER to be specified on the "MAIL FROM" command.

connection to mx2.allows-submitter.com
------
MAIL FROM: recipient(_at_)target(_dot_)com 
SUBMITTER=hostile(_at_)throw-away(_dot_)com
RCPT TO: invalid(_at_)allows-submitter(_dot_)com
DATA
(includes virus or spam as payload)

When mx2 tries to relay to mx1 (the primary MTA), mx1 rejects the
message because "invalid(_at_)allows-submitter(_dot_)com" doesn't exist (or 
has
mailbox full, etc...). Now, mx2 sends a DSN (attaching the payload) to
"recipient(_at_)target(_dot_)com".

"recipient(_at_)target(_dot_)com" (and probably a lot of other recipients in 
a lot
of other domains) is now receiving spam/viruses from <>
(postmaster(_at_)allows-submitter(_dot_)com) and SPF evaluation proves that 
it is
coming from "allows-submitter.com".

Am I missing anything?

The problem illustrated here is that junk mail [containing an arbitrary
payload] can be forwarded via a non-malicious mail server to an arbitrary
address. This is currently a major problem on the internet: I see
thousands of these bounces a day.

The original design of SPF/Classic, which is now the design of
Unified-SPF/Mail-From was intended to prevent this case. It is clear to
see that the design would be successful in this aim.

It is a source of increasing disappointment to me that this working group
has turned away from these technically sound proposals in favour of more
complex, less technically sound, and less clearly directed proposals which
do not have the capability to prevent this relaying.

S.

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/