Use suspend-and-forward instead of store-and-forward

(Ticket opened. Now I need supporting votes.)

SmarterMail uses a store-and-forward process: the SMTP module performs initial checks, then if no problem is found, it accepts the message and closes the incoming connection. If a subsequent process detects objectionable content or a delivery failure, it is too late to reject the message because the submitting server has been told that the message is accepted and consequently the connection has been closed. As a fallback, SmarterMail can only notify the user with a non-delivery report (NDR).

However, SMTP is designed to operate as a suspend-and-forward in process. The submitting server can be put "on hold" while the receiving server attempts to complete the delivery. With this mechanism, if any delivery problem is detected, each server in the chain is notified with a reject status which is relayed back to the start of the chain. No NDR messages are needed because no connections are ever closed.

As evidence, I provide these timeout rules from RFC 5321:

https://tools.ietf.org/html/rfc5321#section-4.5.3.2
• 4.5.3.2.1. Initial 220 Message: 5 Minutes
• 4.5.3.2.2. MAIL Command: 5 Minutes
• 4.5.3.2.3. RCPT Command: 5 Minutes
• 4.5.3.2.4. DATA Initiation: 2 Minutes
• 4.5.3.2.5. Data Block: 3 Minutes
• 4.5.3.2.6. DATA Termination: 10 Minutes.
• 4.5.3.2.7. Server Timeout: 5 Minutes.

In exceptional conditions, such as a failed downstream server, an intermediate server can do store-and-forward or it can simply relay a temporary failure status back to the point of origin and let the origin try later. (I think store-and-forward is really a remnant of the early days when routing was performed with intermittently-available dial-up connections. But now it is being used as a programming convenience,.)

Early IETF documents required NDR reports if a delivery problem is detected after the message has been accepted. More recent IETF documents instruct systems to never generate a NDR (to external senders) because the NDR destination address can be fraudulent, so the NDR report itself becomes another spam message. SmarterMail has not embraced the new guidance.

I am trying to comply with the newer IETF guidance, but SmarterMail makes this difficult. On my incoming gateway, I have Declude discard messages rather than returning them to SmarterMail, since SmarterMail is unable to generate a reject status. In my outgoing gateway, I have a rule to quarantine outgoing NDRs so that they will not be released to the Internet.

But SmarterMail keeps outwitting my defenses. Delivery problems associated with disabled users and overquota users still generate an NDR, and the outbound NDR message is currently bypassing my Outgoing gateway.

The real solution is to re-architect SmarterMail to operate on suspend-and-forward, so that all delivery failures are handled in exactly the same way, as a reject message. It will be difficult, but it is needed.

Gabriele Maoret - SERSIS Replied

12/30/2020 at 5:16 AM

Gabriele Maoret - Head of SysAdmins at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)

Ron Raley Replied

12/30/2020 at 5:52 AM

I agree that SMTP should work this way. +1

I believe this is how Gmail operates.

Ron

Sébastien Riccio Replied

12/30/2020 at 8:52 AM

It is true that nowadays most SMTP servers does most of the checks at SMTP transaction (after the end of DATA command) so it directly accept or reject the mail directly instead of generating NDR.
This is way better and avoid backscatting.

Sébastien Riccio System & Network Admin https://swisscenter.com

3 Replies

Reply to Thread

Related Knowledge Base Articles

3 Replies

Reply to Thread

Tags

Related Knowledge Base Articles