[Mimedefang] Greylisting?

[John Rudd]

Has anyone done a grey-listing setup using mimedefang?  It seems like 
filter-sender would be the ideal place to do it.

For those who don't know how grey-listing works, basically, the first 
time a sender/relay combo tries to submit a message, it has to wait X 
hours before it will be allowed to go through (a real SMTP sender will 
wait and try again on the next queue run, a virus/spam-bot will just 
fail).  After the initial X hour delay, it can send without delays for 
the next Y hours.  If it is a frequent sender (at least one email per Y 
hours), it will only have to wait the first time and never again, 
because the Y hour timeout gets extended each time a new message is 
submitted.

The idea is that, as I said, simple spam and virus senders don't keep a 
mail queue, they just try to send something and then move on if it 
fails.  As long as they aren't trying you multiple times in Y hours, 
you wont ever get mail from them.

This is in contrast with legitimate MTAs where you expect them to keep 
a temp-failed message in their queue for up to 5 days, and retry it 
every 15 to 45 minutes.  You want X to be more than 1 or 2 queue runs, 
but less than 4 hours (the typical amount of time it takes for the MTA 
to warn the sender that the message hasn't gone through yet).  I think 
you also want Y to be less than 3-5 days (typical times for the final 
failure of a temp-failed message).

My high level implementation idea is:

(since I'm not an expert with databases, and don't want to set one up 
just for this, I plan to use a directory, where the database keys are 
the filenames; but you could easily do this as a proper database that 
has 4 properties: sender, relay, record creation time, record access 
time; instead, I'll be using a directory, where files have filenames of 
the form sender:relay, and using the mtime and atime of the file -- in 
the database, you key off of _both_ sender and relay) (note I am using 
mtime for the "creation time", even though that's not what mtime means; 
since I expect the file's contents to never change, I think that should 
work)

0) pick a minimum wait time (X) and a maximum stale time (Y).  I'm 
thinking about X = 2hrs, and Y = 48 hrs.


1) if a message comes in, check to see if the key exists in the database
    a) If file/record doesn't exist, create the file/record (touch -a -m 
it,
       or set the creation and access times to now) then tempfail the
       message/sender.
    b) If the file does exist, and the mtime (or creation time) is 
younger
       than X, then tempfail the message/sender.
    c) If the file does exist, and the atime is older than Y, then
       touch -a -m the file (or set the creation/access times to now),
       and tempfail the message/sender.
    d) If the file exists, mtime is more than X, atime is less than Y,
       then update atime (touch -a for a file), and accept the message.

2) have a second process which runs and cleans out any records whose
    atime is older than Y (semi-redundant to 1c, but it keeps you from
    having too many stale records).  Run the process every 2-3 hours.
    (you could also remove files where the atime and mtime are equal,
    meaning that step 1d never happened, and atime and mtime are more
    than 2X or 3X old ... so they never tried again in a reasonable
    amount of time, even if that's less than Y; so the idea becomes
    "you must retry for at least X hours, but you better not wait more
    than 2X or 3X hours for your first retry"; this would try to account
    for an infected machine that clearly isn't retrying often enough to
    be a reasonable MTA, but is sending a new burst of spam/viruses
    before Y elapses)


Does that seem like the right logic flow for grey listing?

Should I do the "must retry in at least 2X or 3X hours" part in item 2? 
  Or leave that out?

Do the X and Y values seem reasonable?

Does the implementation (with files instead of an actual database) seem 
like it will cause too many problems?