Milter-greylist

10 \u0441\u0435\u043d\u0442\u044f\u0431\u0440\u044f 2016�\u0433. 11:50:50 CEST, "Marcus Schopen lists-yahoogroups@... [milter-greylist]" <milter-greylist@yahoogroups.com> \u043f\u0438\u0448\u0435\u0442:
>Hi,
>
>any best practice how to autowhitelist recipients from outgoing smtp 
>relay on the incoming relay? On the incoming relay one could use 
>urlcheck (any script available?), but how catch recipients from the 
>outgoing relay using milter-greylist and make it available for the 
>milter-greylist on the incoming server?
>
>Ciao
>Marcus

Hi,

As I mentioned, I was looking for something like this (lazily) and did not find. But it was a few years back, and it is a nice to have (really nice) but not life-critical feature so we've managed without and users got used to the current behavior (that initial comms with a remote domain may lag). Our MGL rules use a scoring system, so for reasonably well-managed domains the greylisting delay is either 2 or 25 minutes which is often (alas not always) negligible; suspicious domains (mostly bad matching of DNS entries or consumerish PTR names, poor SPF, workstation OSes according to p0f, etc.) go into hours range so DNSRBLs have chance to speak up. Very few are blacklisted outright by MGL from the first connection, so whatever trickle passes the initial filter goes to spamassassin (which is cheaper than bayesing the whole big incoming stream) that marks suspicious content and the mailer puts messages into spam folders. Little is lost, few spams get into inbox unmarked, users ar!
 e happy.

Yet regarding the feature to pre-whitelist recipients as we send them our emails, I wanted to do something inside MGL code, such as to use the replication protocol to query and feed the grey/autowhite database. For some reason this did not work for me, maybe a daemon instance can not talk to itself this way (I don't think I tried with two daemons, a second one running just for this purpose and replicating back asynchronously, which might work, now that I think of it). Alternative solution inside MGL would be to somehow explicitly use the grey/white/black-listing keywords with formatting strings (probably this also requires hack the code to make it usable like this).

As a solution outside, that sounds like an easy workaround, you could try to whip up a CGI script to tickle with urlcheck, that would detect if email is incoming or outgoing, and based on that either store the expected reverse direction credentials, or find that those already exist and autowl them (for mails coming back and perhaps sender-verification schemes). Maybe it might also hop on the replication protocol to feed the entries into MGL database directly.

You also asked "how to learn of those outgoing mails"? That's easy - run MGL on the outgoing relay (for smaller orgs it may be same as incoming) and have the MTA (sendmail) milter the outgoing/authenticated stream too. Usually there is an ACL early in MGL rules to skip processing (static whitelist) for email that originated locally - but you can also add a few rules on messages that match this ACL (e.g. to call urlcheck or the new keyword in MGL) first, and then whitelist them.

Good luck, and hope this helps (and I hope you're luckier and more persistent than myself to find or implement a solution and share back),
Jim Klimov
--
Typos courtesy of K-9 Mail on my Samsung Android
--
Typos courtesy of K-9 Mail on my Samsung Android