Subject: Will Accepting SUBMITTER Get You Blacklisted?

From: "Michael R. Brumm" <[email-masked]>
Date: Sat, 7 Aug 2004 05:17:47 -0600

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: [email-masked] SUBMITTER=[email-masked]
RCPT TO: [email-masked]
DATA
(includes virus or spam as payload)

When mx2 tries to relay to mx1 (the primary MTA), mx1 rejects the message because "[email-masked]" doesn't exist (or has mailbox full, etc...). Now, mx2 sends a DSN (attaching the payload) to "[email-masked]".

"[email-masked]" (and probably a lot of other recipients in a lot of other domains) is now receiving spam/viruses from <> ([email-masked]) and SPF evaluation proves that it is coming from "allows-submitter.com". 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.

Am I missing anything?

Michael R. Brumm

---

From: [email-masked]
Date: Sat, 07 Aug 2004 09:04:06 -0700 (PDT)

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

> 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.

> (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 "[email-masked]" doesn't exist (or has mailbox full,
> etc...). Now, mx2 sends a DSN (attaching the payload) to
> "[email-masked]".

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.

> "[email-masked]" (and probably a lot of other recipients in a lot of
> other domains) is now receiving spam/viruses from <>
> ([email-masked]) 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

---

From: "Michael R. Brumm" <[email-masked]>
Date: Sat, 7 Aug 2004 17:57:40 -0600

>relayed. The only time the message will get through is if the SUBMITTER value

Of course. I expect the spammer/virus to follow the rest of the SUBMITTER requirements and place "[email-masked]" 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.

>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).

>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

---

From: "Michael R. Brumm" <[email-masked]>
Date: Sat, 7 Aug 2004 18:49:00 -0600

Ok, to reduce confusion, I have changed my discussion to that of the PRA. Accepting based on SUBMITTER implies the PRA check, but obviously doing evaluations based on the PRA-only also has the same attack weakness that I was discussing.

Although this injected forged bounces weakness has been known for some time, it was previously only described as a minor annoyance which had no significant consequence. It is my belief that the attack scenario I outlined shows that it is more serious than that.

Michael R. Brumm

---

From: Graham Murray <[email-masked]>
Date: Sun, 08 Aug 2004 06:16:27 +0100

"Michael R. Brumm" <[email-masked]> writes:

> 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.

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. 

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)

---

From: Shevek <[email-masked]>
Date: Mon, 9 Aug 2004 12:34:54 +0100 (BST)

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

> First, let's assume a domain "allows-submitter.com", who has MTAs which
> allow SUBMITTER to be specified on the "MAIL FROM" command.
> 
> When mx2 tries to relay to mx1 (the primary MTA), mx1 rejects the
> message because "[email-masked]" doesn't exist (or has
> mailbox full, etc...). Now, mx2 sends a DSN (attaching the payload) to
> "[email-masked]".
> 
> "[email-masked]" (and probably a lot of other recipients in a lot
> of other domains) is now receiving spam/viruses from <>

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/

---

From: Graham Murray <[email-masked]>
Date: Mon, 09 Aug 2004 13:31:55 +0100

> do not have the capability to prevent this relaying.

I agree.

But maybe there is room for both. First perform the SPF Mail-From
checks (to verify the mail comes from the sender domain it claims), so
that any subsequent bounces are not sent to innocent parties, and only
if these pass continue to the 'responsible sender' checks to ensure
that the RFC2822 'sender' is compatible with the MTA which originated
the mail to detect phishing etc.

---

From: Shevek <[email-masked]>
Date: Mon, 9 Aug 2004 16:43:20 +0100 (BST)

> the mail to detect phishing etc.

In which case we must persuade Meng to put the Unified-SPF drafts back on
the table for discussion instead of simply gesticulating in the general
direction and annoying the chairs.

I request a formal submission.

S.

---

From: Shevek <[email-masked]>
Date: Mon, 9 Aug 2004 16:43:20 +0100 (BST)

S.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 09 Aug 2004 21:22:22 +0200

Graham Murray wrote:

> maybe there is room for both. First perform the SPF Mail-From
> checks (to verify the mail comes from the sender domain it
> claims), so that any subsequent bounces are not sent to
> innocent parties

So far I fully agree with you...

> only if these pass continue to the 'responsible sender'
> checks to ensure that the RFC2822 'sender' is compatible
> with the MTA which originated the mail to detect phishing
> etc.

...but I don't understand this part.  What do you want to do
if the MAIL FROM test was inconclusive, neither PASS nor FAIL ?

MUAs should display a "PRA" (as specified in core-02 7.5), and
this allows users to detect phishing.  And this feature does
not depend on any 2822 header tests by the MX / MDA, the MUA
can evaluate all corresponding headers:

Resent-Sender / Resent-From / Sender / From in this order, and
if found one address in this header should match the MAIL FROM,
and that's the "PRA".

If there's only a From: header and it doesn't match MAIL FROM,
then treat the MAIL FROM address as "PRA", to be compatible
with 2476 MSAs if they "forgot" to insert a matching Sender.

After this check the MUA has a "PRA" matching the MAIL FROM,
or a dubious mail (e.g. From !~ Sender !~ MAIL FROM !~ From).

If it has a "PRA" it can display it with the SPF result found
in the SPF classic header Received-SPF: (PASS, SOFTFAIL, ERROR,
UNKNOWN, but probably not FAIL, that should be handled before
and never reach a MUA).

So there's only one problem, MUAs must know who generated the
Received-SPF, the phisher or their own mail provider.  But in
theory this could be configured per mail account, when users
enter their mail address / password / host names / etc.

I still don't get the idea why the MX should determine a "PRA",
only the MUA wants to know and display this.  The info passed
from MX to MUA must be in a new header (or in a new parameter
of the Received: header).  No existing MUA knows this new
header / parameter.  Therefore it only works with new MUAs.

If that's the case this new MUA can do the simple "PRA" check,
and display it together with the SPF result found in a new
Received-SPF.  The MX cannot finally judge phishing problems,
it's only a machine.  But the MUA has a human user.

                          Bye, Frank

---

From: "Michael R. Brumm" <[email-masked]>
Date: Wed, 11 Aug 2004 07:26:23 -0600

Michael R. Brumm wrote:
> SUBMITTER allows forged bounces to be injected onto

>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?

>do not contain the spam/virus payload (but that is not the province of

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