enable spamassassin?

[pgentoo]

(05-14-2009 06:18 PM)kilburn Wrote:  I'm quite sure it goes this way:

1. Client connects to postfix
2. Postfix opens a proxy smtp connection against amavis
3. Client sends helo/mail from/rcpt to
4. Postfix makes some checks of it's own
5. Postfix connects to policyd-weight and asks for it's decision (based on ip/helo/mail from/rcpts)
6a. If policyd rejects, postfix rejects too and closes connections to both the client and amavis proxy.
7. Postfix connects to postgrey and asks for it's decision (based on ip/sender/recipient)
7a. If postgrey rejects (greylisting rejects are always temporary, so the remote server should try again later), postfix rejects and closes connections.
8. Client sends the actual mail data.
9. When the data has been received, amavis calls its backends to perform any checks (remember that amavis has a copy of the mail because it has been receiving a copy of all the client's operations).
9a. If configured, amavis passes the message to clamav who checks the message and tells back to reject or accept it
9b. If configured, amavis passes the message to spamassassin, who replies with a reject/accept/bounce and the possibly modified message (headers added, etc.)
10. If amavisd rejects, postfix rejects too and connections are closed
11. If amavisd accepts, postfix acknowledges the message (in the client's connection). Amavisd reinjects the modified message using smtp on a special port
12. Postfix delivers the modified reinjected message to the recipients maildir

Who would have thought that receiving a mail is that complicated?

Thanks for the clarification. But doesn't it make sense to do postgrey checks first? And then do the rest...?

EDIT: Nevermind, I see that amavis is just proxying the request, and not doing much until after postgrey checks pass. This is inline with the logs i'm seeing, where there are a lot of postgrey entries, but very few that make it all the way to amavis.
-
pgentoo