Re: White listing messages processed by a previous milter
On 27.06.20 00:46, Marc Roos wrote: What would be the best practice to whitelist / not process, messages that have already been processed by a previous milter. Maybe set a message header and whitelist on this message header? I would not trust such header. but I maintain a few postfix configurations where port 25 (smtp from the world) is handled by milter and other ports are handled by content filters. this is of course a MTA configuration issue. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The only substitute for good manners is fast reflexes.
Re: White listing messages processed by a previous milter
On Sat, 2020-06-27 at 00:46 +0200, Marc Roos wrote: > > What would be the best practice to whitelist / not process, messages > that have already been processed by a previous milter. > If you've already whitelisted a message and want it to bypass SA, then you will, by definition, have total confidence that your milter does not generate FPs or FNs. In that case, why pass it through SA when it would be much simpler for the milter to pass it directly to your MTA for delivery without any further processing? I've been doing the opposite for years: in my case getmail collects incoming mail and passes it through SA, which sends it to a discrimination program which quarantines spam and passes non-spam to my internal MTA for delivery. After tuning SA to deal with my particular incoming mail stream, this has very few FNs or FPs (which are retrievable from quarantine). This works for my low volume mail stream: there's no reason why higher volume sites shouldn't use a full-monty MTA to feed the incoming stream through SA and a spam discriminator before passing the clean stream to a second MTA for delivery. Martin
Re: White listing messages processed by a previous milter
On 6/26/20 4:46 PM, Marc Roos wrote: What would be the best practice to whitelist / not process, messages that have already been processed by a previous milter. I'm confused. My knee jerk reaction is that's an MTA configuration issue. But I don't think it can be that simple. I can't think of a situation where the MTA would behave differently (under normal circumstances). I would expect that messages coming in a path would always flow through the same set of milters. Hence configuration issue. But, maybe you're in a situation where messages make it to a mailbox through different paths and the LDA is invoking SpamAssassin. Please help me understand the situation that you're asking about. The only thing that comes to mind is to do something similar to what you're saying, add an artificial header before SpamAssassin, that you can have SpamAssassin filter on. Then artificially lower the spam score, or see if there is a way to have SpamAssassin end early without any additional filtering. Normal circumstances allows for situations where a milter earlier in the chain might fail open. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
White listing messages processed by a previous milter
What would be the best practice to whitelist / not process, messages that have already been processed by a previous milter. Maybe set a message header and whitelist on this message header?