The documentation on their spam architecture is inadequate. I worked through their spam design awhile back, and wrote it up, hoping they would make it into a KB article. Since the forum's search mechanism is pretty rudimentary I cannot find it now.
The spam architecture follows the processing stages they use:
- The Inbound SMTP process moves messages from an SMTP session to the "SMTP Arrivals" queue. SMTP Filtering occurs in this phase.
- The Delivery process moves messages from the SMTP Arrivals queue or a hosted user's outbox into the SMTP Departures queue or a hosted users Inbox. Delivery also moves or creates the message in the sender's "Sent Items" folder. Spam filtering occurs in this phase.
- The Outbound SMTP process moves messages from the "SMTP Departures" queue to an external mail system. Outbound SMTP filtering occurs in this phase.
This means that inbound SMTP filtering applies to messages arriving from the Internet via unauthenticated SMTP, as well as messages arriving from IMAP and POP clients via authenticated SMTP. Inbound SMTP messages are processed by both SMTP Filtering and Spam Filtering.
Messages created with WebMail, MAPI, EAS, or EWS do not get checked by spam filtering until they are placed in the user's Outbox, at which point Delivery starts. Spam Filtering occurs and Outbound SMTP filtering may occur, depending on destination.
As you have discovered, messages can go through the same spam process twice, if they are configured into more than one of these three processes. Spam scores do not carry over between processes, so you do not experience double counting if a process is executed in two different phases.
The spam problem is vastly different between unauthenticated and authenticated users.
- Unauthenticated traffic requires assessing sender identity, determining if any identifier has been impersonated, finding the sender's reputation, evaluating whether the sender is guessing to find valid email addresses, and deciding what to do if the sender is new and has no known reputation.
- Authenticated SMTP has no concerns about sender identity, has minimal concerns about From impersonation (depending on your Auth Match setting), has authorized access to a list of valid recipients in the global catalog, and has a presumption that the sender has an acceptable reputation.
All of this means that if you try to do unauthenticated and authenticated spam filtering in the same place, you are going to have a lot of work trying to treat the two groups of messages correctly. I recommend creating an inbound gateway and filtering your inbound unauthenticated SMTP there.
The other advantage of an inbound gateway is that good filtering of unauthenticated SMTP is likely to requires more features than are available in the Inbound SMTP filtering list. The inbound gateway allows you to tune the Spam Filtering options on the gateway differently than the same settings on your mail store server.
If all inbound spam filtering is performed on an inbound gateway, then your mail store server only needs to worry about defenses against insider threats, a topic on which I have no particular advice. You will be trying to configure content filters that will detect a compromised account or insider attack, without blocking any legitimate content of your current users. Based on bad stuff that has escaped commercial outbound gateway services, I doubt that anyone else has figured this out. I am not currently doing any filtering for messages that originate internally,
You should also be aware of how rejects are handled in the different phases. Inbound SMTP filtering occurs while the SMTP session is open. If a message is unacceptable, the submitter is notified immediately with an SMTP Response Code. Messages that are blocked later can be silently discarded or the sender can be notified with a non-delivery report (NDR) sent by email. NDRs are a good idea for messages originating internally, but a terrible idea for messages originating from the Internet.
Most of my spam filtering is done by Declude on my incoming gateway. Declude is invoked through the \Spool\Proc folder, which is invoked after the SMTP Session is closed. If Declude does not perform silent discard, the Declude score is added to the Delivery phase Spam Filtering score. Since the SMTP session is closed and I am unwilling to send NDRs to strangers, I perform silent discard on unwanted messages.