On Tue, 2004-08-10 at 05:42, Mark Shewmaker wrote:
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.)
The Mailbox Domain identified by Submitter can not be used for
reputation checks! This Mailbox Domain does not indicate the origin of
the message, being the entity granting access to the mail stream. There
would be little upon which to base repudiations and thus little gained
from such check. Using this Submitter Mailbox Domain repudiation would
expose the many opportunities for Sender-ID spoofing that still exist,
and harm those left vulnerable by many shared MTA channels.
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.
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.
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.
The white-listing could be based upon the MAIL FROM without using
Submitter. If the PRA is not the RFC 2822 From, what would Submitter
white-listing accomplish? Would this be greatly different from the use
of MAIL FROM? A reaction by large ISPs to the use of Sender-ID could be
to then include a Resent-From header to allow customers an ability to
continue their normal practices. (Saving them a fortune is their support
center.) In such a case, MAIL FROM is still as good, if not better than
Submitter.
So, here SUBMITTER is a *serious* optimization!
This is ignoring the likely outcome of this mechanism and the defensive
strategy likely to result.
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.
I assume you mean Reject messages failing Sender-ID checks.
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. Spam is even smaller at about 4 kbytes.
If the DNS cache hit rate is 80%, assuming the cache can withstand the
added amount of Sender-ID records, the traffic is still 40 kbytes.
Spammers however often employ a wildcard record and random sub-domains,
making caching ineffective. Bandwidth can definitely be a concern, but
Submitter does not offer a solution for this.
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?)
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.
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.
(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.
-Doug