a...@exys.org wrote: > exactly. The point is that scores below 2 are never spam, so i avoid > greylisting. Thats my whitelist (you usually need for greylisting) at > the same time, since i whitelist some hosts in SA.
Interesting set-up, although I don't think it would be suitable for a high-volume server. So what do you use to do this? exim-sa and what greylisting software? > above 2. The njabl hit would have been enough to hit that. It didn't > score above 10, because that would have been rejected at smtp time. > > My guess is that it scored 2 on the first try, then later it would have > scored above 10 due to surbl listings, but awl kicks in and lowers the > score thinking the greylisted mail was an independent message. With most greylisting systems, the temporary reject is before the data section (which helps save bandwidth), so it's hard to know if it's two attempts to deliver the same message, or two independent messages. Not so in your case, however. What is auto_whitelist_factor set at? > >>> And where else did greylisted mail appear in the log? For the >>> mail to be logged as rejected by a greylister *after* its been >>> through SA it must also have been inspected by AWL and therefore it did >>> affect the AWL database. >> > oh right, i could look at the SA log, but i already know it passed SA 3 > times. Worth doing. >> the question is, why it scored hammy? aep, how did it score before >> greylisting? Are you sure you do not have bug in your greylisting code? >> > see above. i'm pretty sure the "bug" is passing the same message to SA > multiple times. Well, by definition that isn't an SA bug. Or are you suggesting AWL should check to see if the same Message-ID has been seen before, and if it has, not score or learn? That would be an extra database lookup, and it would mean AWL would also be disabled for valid mail that had been delayed by greylisting (maybe OK, because it presumably hasn't been seen before). Bayes *shouldn't* allow learning of the same message more than once (it's doesn't if you train it manually), but maybe autolearn doesn't update bayes_seen (??). I think the simplest solution for your config is just: use_auto_whitelist 0 bayes_auto_learn 0 Setting 'tflags URIBL_BLACK noautolearn' etc. on the remote tests would probably mean the AWL decrease would be less, because AWL is then just smoothing out the scores from the local tests. None of this sounds very efficient with minimising DNS lookups and reducing carbon footprints... CK
