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.
allows-submitter.com has the following MX records:
mx1.allows-submitter.com MX preference = 0
mx2.allows-submitter.com MX preference = 10
A spammer/virus connects to mx2.allows-submitter.com because it knows that a
message sent to a secondary MTA is much more likely to cause a bounce than a
rejection.
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)
This is only possible if mx2 implements the extension, and if the extension is
implemented mx2 is also required to check the value of the SUBMITTER parameter
against the header. If it doesn't match the message has to be rejected and not
relayed. The only time the message will get through is if the SUBMITTER value
matches the header PRA.
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".
Which is no different than if SUBMITTER wasn't used - the PRA has to be the
same as the SUBMITTER value for the message to get this far.
"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".
Which again is no different than if SUBMITTER wasn't used.
So, the postmaster at target.com decides to blacklist the
"allows-submitter.com" domain because (somewhat like an open-relay) they are
allowing spam and viruses to be relayed through their MTA.
Relaying per se isn't the issue. This issue arises any time an MTA accepts a
piece of spam and bounces it later to a forged MAIL FROM address. This happens
all the time for a variety of reasons: Not all MTAs check address validity
during the SMTP session, you're dealing with a secondary MX, the recipient is
over quota, the recipient has filtering in place that causes a delivery time
rejection, etc. etc. etc. Indeed, one of the main goals of these schemes is to
try and prevent such messages from being accepted in the first place.
Am I missing anything?
You're missing the fact that SUBMITTER is simply an optimization allowing a
check to be performed earlier in the SMTP transaction than it otherwise could
be; at most it will lead to a message being rejected sooner. By itself the use
or non-use of the SUBMITTER extension neither solves the bounced spam/virus
problem nor makes it any worse.
Ned