> From: "Mason, Shane" <[EMAIL PROTECTED]>
> But I can do that already, by sending an email with a huge attachment direct
> to your SMTP server that has a destination with a name and IP, but no
> physical site. It will stay at your site until your SMTP timeout kicks in.
What is a "physical site"? Does it mean a host or IP address named in the
SMTP envelope that differs from the host of the SMTP server, but that is
not currently reachable by the SMTP server?
How does that mitigate the problems inherent in giant SMTP messages? Who
is running systems that has SMTP spool space for a few 100,000 messages,
each several dozen MByte, each waiting for some next hop to awaken?
> This is, of course, assuming that the RFC still says all SMTP servers must
> accept mail to any destination, and your site is RFC compliant.
Which RFC ever said such nonsense? I thought it has always been legal to
bounce any and all email based on whatever capricious criteria the SMTP
server feels like imposing. That is the basis for one of the 3 major spam
rejection mechanisms.
> What about an SMTP server negotiating a size limit based on a profile for
> the mailbox of the recipient? Or perhaps a hold and verify, so the
> recipient is notified of the document, it's size, who sent it, and at what
> time, and then the recipient could send an ACK or a FIN for immediate
> delivery or immediate bounce BEFORE it travels to the recipient's mailbox.
Note that for good technical reasons, an SMTP (or ESMTP) bounce
does not involve the server merely sending a TCP FIN or a TCP ACK.
Please see RFC 821.
Note also that at least one common SMTP implementation, sendmail, does
not copy directly from the wire into the recipient's mailbox under any
circumstances, for what I think are compelling reasons.
Note also that "notifying a recipient" can be a pretty complicated idea
that could involve waits of days or longer, during which many of us would
prefer not to preserve TCP connections and SMTP client and server state.
(I'm just guessing about what "recipient" is intended to mean, since it
clearly cannot be the notion used in RFC 821 or RFC 822. My guess is that
it means something about the final SMTP server.)
See also RFC 1870.
Vernon Schryver [EMAIL PROTECTED]
