Re: CBV systems - was Re: SMTP Extensions - proper reply code for disabl

On Thu, 15 Jan 2004 15:20:26 EST, Hector Santos 
<winserver(_dot_)support(_at_)winserver(_dot_)com>  said:

> Hmmmmm, unless I am wrong,  I was under the current/modern SMTP design
> assumption the initiating "Message Sender" must remain constant throughout
> the entire multi-host route and that the Return-Path: header is only added
> during final delivery.     This has to be true in order for the final
> delivery to stamp the proper Return Path header with the proper return path.
>
> Am I wrong?
Yes.

It is quite possible that an intermediate system (most likely in the DMZ of a
firewalled company) will find it necessary to source-route or %-hack the
SMTP MAIL FROM such that the final value will be deliverable at
the destination.  Yes, I know 2821, section 6.1 has a MUST about where
to send the notification for source-routed addresses, but (a) it doesn't
apply to %-hacked addresses and (b) there's probably still a lot of places
that can't do it right (i.e. the interior system doesn't know how to route
a non-source-routed address).

Note that this is important for any CBV system, as you're making the
assumption that the call-back can be done in real time even though the
mail you're trying to verify came in via a store-and-forward.

> I believe the statement clearly presumes that an unambiguous return-path
> MUST (not SHOULD) be valid in order for  the delivery of  a"system failure"
> message can be attempted.
The fact that the return-path was valid to within the best-effort attempts
at the time the mail was sent does *not* imply that it MUST (in the RFC sense)
be valid later at some unspecified day.

Back in December, I sent out a mass mailing with a specially crafted MAIL FROM
so bounces went to a controlled location.  Said address is no longer valid - I 
disabled
it a week after I did the mailing.  Where does this fit in your 'MUST be valid'?
It's quite possible some borked system took 8 days to bounce a mail, and the
bounce mailbox evaporated before the bounce mail arrived.

> > AFAIK MS Exchange does verify the syntax of an address during SMTP
> > transmission, but _not_ the existence of the recipient address.
> I believe this is a matter of implementation as it is possible to hook into
> the RCPT TO: state.
RFC2821, section 6.1:

   Some delivery failures after the message is accepted by SMTP will be
   unavoidable.  For example, it may be impossible for the receiving
   SMTP server to validate all the delivery addresses in RCPT command(s)
   due to a "soft" domain system error, because the target is a mailing
   list (see earlier discussion of RCPT), or because the server is
   acting as a relay and has no immediate access to the delivering
   system.

In other words, if you're down and your secondary MX grabs it, it probably
can't cough up a User Unknown. And then of course you have to decide how to do
CBV if a secondary MX is forwarding...

> what happens once the data is received.  If we are to believe AOL.COM's
> claim as the largest database of email users, then why is it they do dynamic
> validation of the recipient address?   Why don't they delay the process?
Very simple - if they '250 OK' the mail, they commit to taking responsibility 
for
the mail.  When you're rejecting a billion spams a day, the LAST thing you want
to do is say '250 OK' and then get stuck having to deal with the message.
There's a lot of sins that the spec permits before you 250 it that you can't do
once you 250 it:

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility
   seriously.  It MUST NOT lose the message for frivolous reasons, such
   as because the host later crashes or because of a predictable
   resource shortage.

If you look at the Sendmail code, there's a number of places where it hits
an extremely performance-painful fsync() or fdirsync() call, simply to protect
against crashes. All that extra I/O *hurts* when you're doing high-throughput
mail systems.

pgpZ3hqWY8pX7.pgp
Description: PGP signature