Ned Freed wrote:
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.
Of course. I expect the spammer/virus to follow the rest of the SUBMITTER
requirements and place "hostile(_at_)throw-away(_dot_)com" in the PRA.
Otherwise, the message probably wouldn't get onto mx2.
Much of the rest of your message seems to imply that the PRA checking somehow
prevents forged bounce injection, and I don't see how it would.
Ned Freed wrote:
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.
I think you need to re-read my message. I don't see anything in your argument
which would prevent the attack scheme I outlined from occurring. SUBMITTER
allows forged bounces to be injected onto forwarders (even with PRA checks).
The bounces go to a third party (the MAIL FROM), which may see the forged
bounces as spam/viruses from the forwarder (not the injector). This could cause
the forwarder (which is only following the SUBMITTER protocol) to be
blacklisted.
This means that with either 1) a throw-away domain or 2) a hijacked domain,
someone could attack any domain with MTAs supporting SUBMITTER and make them
appear to be sending spam/viruses in (what would appear to be) fake bounces.
These messages would come directly from the attacked domain's MTAs and would
pass SPF evaluations, making them look very much like they are fake bounces.
Postmasters receiving these messages might consider themselves to be under
attack from the attacked domain, thus causing the attacked domain to be
blacklisted.
SRS and DBBF do not appear to have this weakness.
Just to make sure that our terminology is clear:
forged bounce = bounce created when an MTA bounces a message that was forged,
usually occurs when a spammer or virus sends out messages as someone else.
fake bounce = bounce that has no complimentary message, usually a virus
creating a fake DSN (spammers rarely use this).
Ned Freed wrote:
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.
SUBMITTER is more than just an "optimization" to allow the 2822 PRA to be seen
at the 2821 level. It is a forwarding scheme designed as an alternative to
envelope-from rewriting schemes like SRS and DBBF.
See http://www.michaelbrumm.com/spf-forwarding.html
Michael R. Brumm