Michael R. Brumm wrote:
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.
Graham Murray wrote:
Which can be avoided by the forwarder doing SPF classic (or
equivalent) checks to validate the MAIL FROM, and rejecting the mail
if this fails, as well as performing SUBMITTER checks. Which is why I
think that it is important that whatever may be decided about PRA,
SUBMITTER and RCF2822 checks, that it is still important to do perform
MAIL FROM checks to prevent such injections.
I agree. Validating the MAIL FROM should be a requirement, and the
SUBMITTER/PRA evaluation should never allow a MAIL FROM failure to be
bypassed. Otherwise, the attack scenario leaves a gaping security hole which
spammers, viruses, and DOS attackers will use.
If however, the MAIL FROM evaluation is a MUST, then I'm not sure how the
PRA is relevant at all... If MAIL FROM is the primary (and non-overridable)
evaluation scheme, then all forwarded mail will use rewriting. So, the PRA
will not match the sending MTA. Wouldn't that just break forwarding?
Graham Murray wrote:
Your scenario also shows that it is unwise to include the message body
in bounces. Forwarder is less likely to be blacklisted if the bounces
do not contain the spam/virus payload (but that is not the province of
this list)
While it is true that *not* including the message body in bounces would
prevent the spread of many viruses, it would not mitigate this attack by
much.
1) Volume could be the deciding factor: If I get 1,000 fake bounces to my
postmaster account from the same domain, I'm probably going to blacklist no
matter what is contained in the bounce payload.
2) If you include the Subject of the message in the bounce, it can include
the spammer's/virus' payload. For example:
Subject: Hungry? Visit http://www.get.your.freefood.com/
or
Subject: Why Are You Getting This? Read: http://www.stop-these-messages.com/
The page could then contain the real spam, or a browser buffer-overrun
exploit which propagates the virus.
So, are the current MARID proposals going to allow this? If so, is this
going to be mentioned in the "Security Considerations"?
Michael R. Brumm