RE: Does marid-submitter-02 really make sense?

[Mark Shewmaker <mark@xxxxxxxxxxxxxxx>]

On Tue, 2004-08-10 at 14:34, Douglas Otis wrote:
> On Tue, 2004-08-10 at 05:42, Mark Shewmaker wrote:
> > On Tue, 2004-08-10 at 06:02, Shevek wrote:
> > 
> > 3.  Any other not-directly-SenderID test based on SUBMITTER could
> >     be substituted in (1) or (2) above, such as domain-based reputation
> >     tests.
> > 
> >     (Or full-email-address (!!!) based reputation tests.)
> 
> The Mailbox Domain identified by Submitter can not be used for
> reputation checks!

Sure you can--you can see if you have white-listed that PRA yourself, or
if your trusted friends have--thus giving you reason to believe claims
made by this PRA,

Or you could filter out PRAs with bad reputations--those appearing on
domain-based block lists.

This isn't as useful as a sender_agents based end-to-end trust chain,
but then again, I did put this "optimization" under the "boring, minor"
heading.

> Neither Sender-ID nor Submitter stop bounces as there are no checks
> against the MAIL FROM.  As mail, at many nodes, operates using a store
> and forward mechanism, there will always be ample opportunity to create
> a bounce.  This example is applying a per recipient white-list at the
> initial MTA receiver.  This assumes all MTAs have been provided these
> per-recipient white-lists.  This assumption is flawed as there will be
> configurations where this does not apply and spammers are expert at
> finding them.

The problem comes with configurations with per-recipient controls.

That's the case I'm worried about.

If you're doing per-recipient white-lists, and you don't have SUBMITTER
but you want to do SenderID PRA checks anyway, you have to check after
DATA.

But since you can't reject per-recipient after data, you have to bounce
after data instead.

But you can't safely bounce after data unless you've had an classic SPF
PASS result.

And that's a opportunity for spammers to have you send out forged
bounces, if you've put yourself into a position to have to send out
potentially forged bounces or throw away accepted mail.

> > So, here SUBMITTER is a *serious* optimization!
> 
> This is ignoring the likely outcome of this mechanism and the defensive
> strategy likely to result.

I meant it a bit tongue-in-cheek.

If you do get SUBMITTER, then you don't have to worry about being used
to generate bounce spam, since you can do per-recipient rejects. 
(Obviously, there's a problem if another machine of yours has just
relayed the message to you--so your rejecting the message would cause it
to bounce the message--but that's a separate vulnerability in your
setup.)

And so you don't have to do all this extra work to counter possible
bounce forgery attempts directed at you.  Hence, "optimization."

> > 2.  Run SPF Classic tests on MAIL FROM, and *bounce* messages failing
> >     SenderID tests.
> 
> I assume you mean Reject messages failing Sender-ID checks.

No, I actually mean "bounce."

If you are sent a message without SUBMITTER, you have to do SenderID
tests after data.

But if one recipient's policies has you accepting that message and the
other has you not accepting it--after DATA you can't reject per-user, so
you have to bounce instead.

But you're stuck if you can't safely bounce if you don't have a full SPF
PASS.

> > Either way, your bandwidth is sucked away like crazy.
> 
> This ignores the required 10 host_checks() functions calls.  Assume each
> TXT record references 8 MX records which then requires 5 A record
> lookups, as in the example by John Levine.  That would be 400 DNS
> lookups resulting in about 1.3 queries per lookup (520) to arrive at the
> 400 answers.  If each query resulted in a normal mean of about 100 ms,
> that would be 52 seconds, well within the 200 seconds alloted by the
> draft.  If at about 400 bytes per record (counting both directions), the
> resulting traffic could be over 200 kbytes of UDP traffic, for about 8
> kbytes of an average message.

But at worst all these queries should be locally cached by the time you
get to the first RCPT TO: value.

So if your test code doesn't cache data itself, you're just querying dns
records cached on your own machine, or on a machine very close to you.

And two of the spf test libraries actually do caching internal to the
libraries.

I'm not very worried about DNS bandwidth.

> It seems refusing to accept multiple recipients, as you indicated, on a
> normal basis would arrive at the same result.  This would work with or
> without Submitter, when applying per recipient white-lists at the MTA. 
> This could be seen as a means to avoid bounces at all costs, to bolster
> Sender-ID that does not check MAIL FROM. 

Yeah.   I'm wondering if, were any RFC to come out for an smtp extension
allowing per-recipient after-data rejects, if it would soon become
acceptable to give "too many recipient" errors on second and subsequent
recipients when the sending MTA (!) doesn't support such an extension.

> > If you're given SUBMITTER, you can do per-recipient rejects safely, of
> > course.  But folks who want to trick you into sending their bounce spam
> > won't be all nice and give you a cool SUBMITTER to play with--and
> > without SUBMITTER you have this yucky issue.
> 
> It seems you have concluded Submitter is not an optimization after all. 
> This problem of multiple recipients is only when they share the same
> receiving MX server as well.

It is a meager optimization for the single-recipient case, but in the
multiple-recipient case, it's an "optimization" in that it allows you to
avoid wasting bandwidth that's necessary to waste if you want to avoid
the security issues inherent in doing per-recipient after-data checks.

> > (Side note:  If you do get SUBMITTER and SUBMITTER!=PRA, then it's safe
> > to reject after DATA for *all* recipients, because this is clearly
> > either a corrupt or forged mail transmission.)
> 
> That assumes there is a check made at this point.  This is the great
> downside when allowing Submitter.  This check becomes optional and the
> modicum of security goes out the window.

Without sender_agents, which has end-to-end tests, I don't see why it's
so bad if some implementations skip the required SUBMITTER==PRA test,
because if you got a message with SUBMITTER!=PRA where the SUBMITTER
value would have caused you to accept it if it were equal to the PRA,
then the sending machine could have just added a "Resent-From:" at the
top of the body headers to have had it pass that SUBMITTER==PRA check.

I don't see how the fact that it didn't bother to fill in some paperwork
mean that there's a security check.

(Now, if Resent-From: included some cryptographic checksum of the rest
of the message, that would be a different story--but it doesn't.)

-- 
Mark Shewmaker
mark@xxxxxxxxxxxxxxx