ietf-mxcomp
[Top] [All Lists]

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

2004-08-10 05:39:16

On Tue, 2004-08-10 at 06:02, Shevek wrote:

It does permit early failure, but if implemented correctly, one would hope 
that the spammers would be forced to use the success case. Thus this 
optimisation offers no saving of bandwidth, CPU or anything else.

Nah, there are some minor, meager optimizations.

And there is a super-duper, super-serious, point-blank, shockingly huge
optimization.

First the boring, minor optimizations:
--------------------------------------

The existence of a SUBMITTER in the MAIL command could provide meager
throughput optimizations, even in the success cases:

1.  If the receiving MTA is doing SenderID tests and no SPF-Classic
    tests:

    Then the receiving MTA could immediately start doing DNS
    queries and Sender-ID tests at MAIL time, even if it doesn't
    act on the results until after DATA.

    So instead of taking N network-limited milliseconds to do the
    Sender-ID test after data, tacking N to the length of time
    otherwise needed to process the hole message, it could do that
    N milliseconds worth of work/waiting in parallel.
    
2.  If the receiving MTA is doing SenderID tests *and* Classic SPF
    tests:

    Then there's going to be a short delay at MAIL FROM *anyway* just
    to do the classic SPF tests.

    I'm *guessing* the classic SPF tests would take about the same
    amount of time as the Sender ID tests, so why not just do them
    in parallel?

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

However, since these are merely optimizations, and probably not overly
noticable ones at that, I wasn't big on any requirement to use
Submitter.  (At one point way back when there were flag days and the
like where you'd be required to use Submitter.)

The shockingly huge optimization:
---------------------------------

***HOWEVER***, there is one serious advantage to using SUBMITTER that I
had completely forgotten about:

           Per-Recipient Rejects.

Imagine that one recipient has white-listed a given PRA, and a second
recipient hasn't--and so there's a situation where an incoming message
should be sent to only the first recipient and not the second.

Here are three possibilities for that situation for a receiving MTA:

If you're given SUBMITTER:

  Possibility 1:   Accept the first RCPT TO:
                   Reject the second RCPT TO: with 5.7.1
                   Accept DATA.

If you're not given SUBMITTER:

  Possibility 2:  Accept the first RCPT TO:
                  Accept the second RCPT TO:  
                  Accept DATA.
                  Run SenderID tests.
                  Find the second RCPT TO: fails SenderID tests.
                  BOUNCE the second RCPT TO with 5.7.1

                  This choice means you're running the risk of being
                  a source of forged bounces if you didn't also do 
                  Classic SPF tests.  Oops.

  Possibility 3:  Accept the first RCPT TO:
                  Reject any subsequent RCPT TO:  "too many recipients"
                  Accept DATA.

                  You soon get another connection from the same MTA.
                  Reject the first RCPT TO: with 5.7.1 (which was
                                                        recipient #2 
                                                        earlier)

                  You're supposed to always be able to accept 100 
                  recipients, but if you always max out at one
                  when you don't have SUBMITTER, then you can safely
                  do per-recipient rejects that way, without bouncing.

So, here SUBMITTER is a *serious* optimization!

So if you allow recipient white-listing, you either have to either:

1.  Max out at just one recipient, and get 100 separate connections for
    100 separate attempted recipients,

    OR

2.  Run SPF Classic tests on MAIL FROM, and *bounce* messages failing
    SenderID tests.

Either way, your bandwidth is sucked away like crazy.

But wait--it's worse!!

What if you chose option (2), running SPF classic and doing SenderID
tests--you *still* can't safely bounce unless you get an SPF pass
result!

That means that if you're running SenderID tests with recipient
white-listing (and hopefully with sender_agents, plug-plug), and your
MTA gets a connection without SUBMITTER, the only safe way to proceed is
to:

   Run SPF Classic tests on MAIL FROM:

   If result==PASS:
      Accept as many recipients as you like.
      Bounce messages failing SenderID tests.
   else:
      Accept only ONE recipient maximum.
      be prepared for multiple reconnects.

(Anyone want to suggest an SMTP extension for after-data per-recipient
rejects?)

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.

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

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com