Eliot Lear wrote:
On 10/30/09 7:24 PM, John Levine wrote:
Signing the envelope strikes me as one of those things that sounds
nice, but when you try to work out the wa you'd use it in a practical
application, it turns out not to solve any interesting problems.
I can't say, but I do know that many of us toss a whole lot of mail at
EHLO, some at MAIL FROM:<> and some at DATA.
These are normally site pattern specific, but for our site, we see
EHLO/HELO: 10% is rejected or the client drops
MAIL FROM: Delayed Verification until RCPT TO is known
RCPT TO: 51% are rejected with bad RCPT TO addresses.
Locally Unknown or unauthorized to relay.
Of the remaining that get pass RCPT TO, MAIL FROM is then checked with
a breakdown:
1.5% Local Rules
29.8% DNS RBL rejections
6.6% SPF rejections
62.1% CBV (Call Back Verification) Return Path rejections
The main reason for the MAIL FROM delayed verification was because it
offered a huge +50% DNS lookup overhead reduction. FYI, this
technique is discussed in RFC 5321 Section 3.3:
......................................Despite the apparent
scope of this requirement, there are circumstances in which
the acceptability of the reverse-path may not be determined
until one or more forward-paths (in RCPT commands) can be
examined. In those cases, the server MAY reasonably accept
the reverse-path (with a 250 reply) and then report problems
after the forward-paths are received and examined.
Normally, failures produce 550 or 553 replies.
You (levine) and I are looking at two different problems. I don't
think that storage of the message is the issue, although there is
a cost. As I mentioned earlier, there are some sites that still
pay a whole lot for bandwidth.
+1, in the past,scaling out (more machines) was the solution. Today,
scaling up is more feasible and cost effective due to faster
multi-core machines, more memory, VM, better integration with the
backend, to share information among threads, etc.
We find a few issues due to SMTP current design:
1) SMTP implicit 451 retries for server drops.
2) More 5322 technologies requiring a payload reception
for processing.
3) No "Keep Alive" concepts for lenghty DATA processing.
Because of this SMTP is encourage to accept all transactions for
delayed processing. See RFC 1047 "Duplicate messages and SMTP"
IMO, this is old and based on lower bandwidths where SMTP level delays
and/or drops were more costly. Today's hardware makes it more
feasible to speed up the SMTP transaction.
Overall, since the SERVER is encouraged to not drop connections and to
allow clients to gracefully end the session with a QUIT, load
balancing vs connection balancing becomes more of a challenge.
--
Hector Santos
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html