ietf-mxcomp
[Top] [All Lists]

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

2004-08-10 23:01:42

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(_at_)primefactor(_dot_)com