 |
 |
Both of you (Russell & Chris) are more or less right. I would say the following is probably more information about greylisting than you care to know, but I don't think that is true since you were the one who asked :) The most important factor in greylisting is the triplet (or tuple) that was mentioned: x The connecting/source IP Address x The HELO/EHLO envelope-from x The envelope-to A sample (but modified) entry from our database looks like: GREY|0.11.22.33|<[log in to unmask]>|<[log in to unmask]> |1175734038|1175748438|1175748438|1|0 In this example (from left to right)... * The entry is greylisted * The connecting IP Address is 0.11.22.33 * The envelope-from is [log in to unmask] * And the envelope-to is [log in to unmask] * The first time we saw this exact tuple was Wed Apr 4 20:47:18 EDT 2007 * The time that this entry will pass from being GREY to being "acceptable" is Thu Apr 5 00:47:18 EDT 2007 (only if they retry by this time!) * The time that this entry will expire is also Thu Apr 5 00:47:18 EDT 2007 (if they do not retry by this time) * The number of times this particular host has received a temporary reject or a block is 1 * The number of times this host has been able to pass mail through to our system is 0 As you can see, if potential_spammer's mail server does not resend within 4 hours, the entry in the database gets rejected, and the whole process starts over. But, as you mentioned if [log in to unmask] sends a completely different to that same user, from the same IP Address as before, it would mark it as a second attempt in the database and therefore move the entry from GREY to "accepted." Another scenario I'd like to lay out is something Russell touched upon, which is the "it doesn't even have to be to the same user" Again, you have this mostly right, I just want to expand on it a bit, and we'll stick with some of the same info from above, but this time I will show you two entries: GREY|0.11.22.33|<[log in to unmask]>|<[log in to unmask]> |1175734038|1175748438|1175748438|1|0 GREY|0.11.22.33|<[log in to unmask]>|<[log in to unmask] edu>|1175736237|1175750637|1175750637|1|0 Now, in this example, potential_spammer sent two different messages within 45 minutes of each other (do a 'date -r' on the first 11757 numbers for both entries if you are unix). For now, we'll have to assume that his mailer is going to retry to send the temporarily rejected email after 1 hour instead of the usual 10 - 20 minutes. So, one hour passes, and the first entry moves from GREY to "accepted" but the second entry remains GREY, so now our spamdb looks like this: WHITE|0.11.22.33|||1175734038|1175737638|1178848038|2|0 GREY|0.11.22.33|<[log in to unmask]>|<[log in to unmask] edu>|1175736237|1175750637|1175750637|1|0 In this scenario, one of two things will happen. A job that runs out of cron to regularly run a bit of maintenance will catch this, and automatically move the second entry from GREY to "accepted" -OR- The host will end up retrying before that cronjob runs and get itself moved into that category as well. In our case, we run the spamd-setup (a.k.a. the script I just mentioned) every 20 minutes, but it all depends on whoever set it up (if at all). Whew, well now its really late, and I'm really tired, and I've exhausted just about all my knowledge on greylisting. I can only help it makes sense to you all in the end. For more info: Here's an online epoch time converter: http://www.perlservices.net/en/programs/epoch_converter/epoch_converter.html Here's the man page on spamdb: http://www.openbsd.org/cgi-bin/man.cgi?query=spamdb&sektion=8&arch=&apropos= 0&manpath=OpenBSD+Current Feel free to ask anymore questions about greylisting as they come to you, and I hope this provides some good insight into the process! ./brm