Some of the e-mail passing through my server is forwarded to external accounts.
Unfortunately, my upstream SMTP-server is very picky about spam -- and rejects some of the legitimate messages as such. When this happens to the forwarded mail, I get the bounces (as the postmaster) -- not the originators.
I understand, that this is because sendmail queues the messages locally, disconnects from the relay, and only then proceeds to forward them further. If the further forwarding breaks for any reason -- such as because the next relay misidentifies the message as spam -- my sendmail is left to hold the pieces.
Can things be configured so that the forwarding begins immediately instead (as soon as the forwarding destination is determined)? The status -- success or failure -- can then be communicated directly to the previous relay still on the line...
If sendmail can not do it, can any other MTAs? Thanks!
Answer
No, it's not possible as it's not implemented with any wide spread SMTP software; you would have to program your own SMTP server that supports this kind of behavior, which would be out of scope on Serverfault. In this answer I explain, why all MTAs have implemented the SMTP protocol very similarly, using queue, and how that is the best way to accomplish all requirements of the protocol.
A mail transport agent MTA always either denies a message or accepts and queues it, based on its own settings. Then, it's relayed or delivered from the queue.
That's because
there can be both permanent and temporary errors. If the MTA can't connect the nexthop immediate, it'll try again later and bounces only if the delay reaches the limit set. Neither can it wait for another MTA to respond before closing the connection, as it may have other messages to deliver first.
there can be several recipients. While a client can simply list all recipients at once with
RCPT TOcommands, the message can be finally delivered to several other servers, of which some can be available now and some later. Furthermore, the MTA can't open all these connections at once during the initial connection and wait for their responses. There's no practical reason to have totally different workflow for messages with a single recipient.it should always be clear which MTA currently has the responsibility for delivering the message. (This has been explained by examples in MadHatter's answer.)
That's just how SMTP was designed. Rather than syntactical requirement for the connection commands this leads to very similar architectures; Sendmail, Postfix and even MS Exchange has separate components for sending and receiving mail.
- The SMTP server component receives mail and adds it to the queue.
- Then, separate SMTP client tries to send it further to other MTAs, or if a recipient is local, the message can be saved to a file or passed to a mail delivery agent MDA, e.g. Procmail.
The requirement still comes from the SMTP specification; RFC 5321 2.1 on SMTP model basic structure:
Fully-capable SMTP implementations, including the relays used by
these less capable ones, and their destinations, are expected to
support all of the queuing, retrying, and alternate address
functions discussed in this specification. In many situations and
configurations, the less-capable clients discussed above SHOULD be
using the message submission protocol (RFC 4409) rather than
SMTP.
And a bit further:
In other words, message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can
occur in a series of hops through intermediary systems. In either case, once the server has issued a success response at the end of the
mail data, a formal handoff of responsibility for the message occurs:
the protocol requires that a server MUST accept responsibility for
either delivering the message or properly reporting the failure to do
so (see Sections 6.1, 6.2, and 7.8).
