I can help with some of this while you hope for an employee post. This describes inbound mail only, except for the last sentence.
SMTP session sequence, summarizing RFC 5321:
Sender: Helo command
Receiver: ack or nak
Sender: MailFrom command
Receiver: ack or nak
Sender: Recipient To commands (one at a time)
Receiver: Recipient verification ack or nak (for each recipient address)
Sender: Data command
Receiver: OK to proceed
Sender: <eml file transmitted>
Sender: end of data (blank line)
Receiver: ack or nak
End of SMTP Session
After the SMTP session is closed, if the message becomes undeliverable, the IETF standard says that a non-delivery report should be sent to the sender, using the SMTP Mail From address as the destination. SmarterMail allows this to be disabled, which is wise.
SmarterMail actions:
During SMTP Session
- Blocklist rules on IP, HELO, SMTP address, or SPF Failure are enforced by rejecting every Recipient To command as invalid. This occurs whether recipient verification is enabled or not.
- If Recipient Verification is enabled, invalid recipients are also reported in response to the Recipient To command. Warnings:
- On a prior build, I discovered that if recipient verification is enabled on an inbound gateway, and the connection to the backend server fails, then the message is rejected. I complained about this, but I don't know if it was fixed or not.
- I also worry that Recipient Verification puts a non-trivial load on my main server, and I worry about helping directory harvesters, so I run with it disabled. Instead, I do a recipient verification call from Declude, using a database query instead of an API call. (The database table is updated hourly using an API call). I quickly and silently discard messages with no valid recipients.
- After end of data, the remaining SMTP Filter rules are applied and weights accumulated. The low, medium or high spam action may be activated. One of those options is to reject the message, which will notify the sender.
- If the message is not deleted, the weights are reset back to zero. Some SMTP Filter rules can be executed again, in the next phase, to put weights back in.
- All of this is logged in the SMTP log.
After the session is closed, the Proc folder may be invoked.
- If the Declude check is enabled or the "Use Spool Proc folder" option is enabled, two files are dropped into the Spool\Proc folder. The .HDR file contains message metadata, including SMTP information that is not part of the messages. The .EML file contains the message.
- SmarterMail forgets about the message until it reappears in the Spool folder, so Declude can perform a silent delete or a quarantine hold. Otherwise, Declude reports a weight into the .HDR file and moves the files up to the Spool folder.
- All of this is logged by Declude or equivalent program since SmarterMail is not involved.
- Of course, if this feature is not enabled, SmarterMail drops the same files directly into the Spool folder.
Once the files appear in the Spool folder, the Delivery phase starts:
- The configured Spam Checks are performed, and weights accumulated. Details of this are logged in the Spam Checks log. Summary information is in the Delivery log. I cannot speak to the exact sequence, but I don't think it matters because the purpose is to accumulate a total weight.
- I don't use other callout programs like rSpamD or SpamAssassin, but I think a timeout error will occur if these programs are invoked but fail to respond. After trapping the error, I expect the delivery process will continue with zero weight added by the failed call.
- After all Spam Filter Checks are applied, the total weight is used to detect if the low, medium, or high spam action should be applied.
SmarterMail only deletes a message if one of the Spam Weight rules tells it to do so.
Edit: after all of the above, Spamfoo runs ( if it is enabled). Spamfoo never did ards a message.
My understanding of the effect on client message submissions:
- SMTP filtering rules will be applied to message submission from IMAP and POP clients using authenticated SMTP.
- The Spam Check rules will be applied to every message submitted from any client.
Outbound Spam filtering rules are applied before a message is delivered to an external destination.
Hopefully others can catch any mistakes in my understanding.