-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alessandro Vesely wrote: > Josh Grebe wrote: >> Hello, >> >> I have been comtemplating writing a pre-DATA hook into courier to >> allow for more >> efficient greylisting. I guess it would actually hook into the RCPT >> TO: handler. > > That is much more lightweight for the receiving server. > >> The biggest problem with the current method (in my opinion) is that >> it runs so >> late in the process, after having already recieved the message. It >> also uses >> hashes of the entire message, which seems to me to be a level of >> paranoia that >> will cause more problems than solve. > > One can only take the digest after receiving the body. > Those md5's should be done carefully, as a sender might rewrite MIME > boundaries on the fly, assigning random values as required by the RFC. Do those need to change on every retry as well? E.g. are they rewritten / parsed as the message is send? > > > Some headers may possibly change, reflecting the status of the message > that changes as a consequence of the sending attempt. The message id should stay the same, but that also still requires receiving the whole body. > > > Digesting the message subject might suffice, but it still requires > receiving the whole body. > >> If each successful message stores remote address, sender email, and >> recipient >> email, a "2 out of 3" test seems pretty reasonable to me. >> >> Has anyone seen a situation where the MAIL FROM: changes on a >> retry? I'm >> thinking of things like mailing lists that automagically handle >> bounces, things >> like that. > > Yes, an example is mentioned in Dino's blog (url below). > > The remote IP address can also change, after load balancing or > more intricate sending arrangements. We could record the network > block, either after whois data or guessing. Whois lookups would be pretty heavy, but some easy rules could apply by as looking at the netblock or domainname. The domain-part is unlikely to change and courier should have done a DNS-lookup so all needed information should already be available. > > > What about the HELO name? HELO may/will change also when the message is send through another server. > > >> I'm interested in any comments or criticism. > > IMHO greylisting rules out technically poor spammers: it is easy > to write a script that sends the same message to each recipient > in a big list. > > Parsing the return code and distinguish 4xx from 5xx is a bit > more difficult. However, doing a few retries in an inner loop > is still easier than writing and then reading a 4xx-failed list. > Waiting a finite amount of time (say 30") for each address would > take too much time. They will adapt, even virusses and may get intelligent enough to understand 4xx. But not as long as only a minority uses greylisting. And I would think the biggest advantage of greylisting is the delay. > > > If the spammer then sends further messages to the same list, > greylisting can assume that the spammer also changes the bounce > address, or else it can use digests. > > However, greylisting after DATA could be smarter than that. > There is no point in greylisting a message that bears a valid > crypto signature, nor one that passes a bayesian test well. > > See also Pyzor, which calculates digests of parts of mail, and > matches it with what other people have gotten > http://pyzor.sourceforge.net/ Those are dangerous assumptions. Bayesian tests can be defeated. Checking Crypto-signatures brings it's own problems as well. The great thing about greylisting is the delay. Besides that greylisting filters out technically poor spammers, 30 minutes is enough time for spam and phising attempts to be included in DNSBL's, URLBL's Pyzor, Razor, DCC, etc. This is in my opinion the biggest benefit of greylisting. > > >>> Dino Ciuffetti wrote: >>>>> >>>>> I'm testing greylist.py pythonfilter module for courier-mta. I >>>>> wrote a little consideration about it. You'll find at >>>>> http://www.freenux.org/~mm/wordpress/?p=6 >>>>> >>>>> Ciao, Dino. > Kind Regards, Sander Holthaus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFEM49kVf373DysOTURArltAKC8GZvSqFb1+kRGCCmdQaK731sXzgCgwSZn X3m3kBTaYJsmHtU6raxw1I0= =94jU -----END PGP SIGNATURE-----
------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
