At 07:27 PM -0700 on 08/09/2010, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote
about Re: Processing after the end of DATA:
One final point. This is a situation where it's useful to distinguish between
submission and relay. In the case of submission, there's usually a person
sitting there waiting for the message to be sent, so a shorter
timeout not only
makes sense, you're going to have very little luck convincing client
authors to
use a longer one. Relays, OTOH, tend to be much more tolerant of delayed
responses. There are of course all sorts of ways to make submit operations
responsive than relay operations.
There is a simple way of distinguishing relay from submit. Run your
relay on Port 25 using the name from your MX record. Run submit using
a DIFFERENT FQDN (and IPN) on Port 587 (and if you want to allow
Luddite MUAs that will not allow the user to request Port 587, allow
Port 25 connections). So long as it comes in on Port587 it is a
submission. NO Relay will come into the MSA via Port25 since relay
will get the correct server via the MX record given the different
host IPN. The only false positive for relay would be if the MUA is
misconfigured to connect to the MTA as opposed to MSA server via
Port25.