Milter-greylist

I've just been reading this thread for a while and don't really have an 
opinion. But I developed two thoughts in the meantime.

- Do we need that much information stored as we do now?
- Do we need to have this info shared in realtime?

I think the answer to both is no.

- amount of information
what for do we need sender and recipient email address? Greylisting is a 
technical way of blocking mail servers that do not retry. From and to 
doesn't matter. (From does matter if you whitelist by SPF, but you don't 
need to store it.) If a mail server retries then it will eventually 
deliver all its mail, no matter which sender or recipient. Doesn't make 
sense to artificially delay that.
Yes, there's lazyaw, but the whole tuple is still getting saved at the 
moment and it's only "active" for matching. 
If we need less information we can store and share less information and 
have to process less information, which would be desirable for many uses, 
including a DBMS backend and for scaling. Much less actually, an IP 
address is much shorter than two email addresses. I think this would also 
make a good default.

- realtime sharing
do all servers in the cloud need to know any "event" immediately? I don't 
think so. In general, you can assume that the "next" mail from the same 
source (be it a retry or a completely new one) will either follow in a 
time period where the tuple (or single IP, see above) would still be 
(grey- or whatever-)listed even for the one server model or in a time 
period where there was enough time to share any necessary information for 
acting upon it "gradually". If it is true that the info doesn't need to be 
shared "immediately", what about using a "revolver" scheme? Given you have 
A - Z servers. Each, say, 5 seconds they contact *one* peer for updating 
in one direction. e.g. A -> B, B -> C, ... , Z -> A. So, for an already 
big cluster of ten servers this would take about one minute. Isn't that 
enough of a time period for synchronisation? If it is done this way I 
assume it uses much less ressources (in CPU and bandwidth) and may thus 
also easier accomodate if a DBMS gets used as a backend (on each machine).

As for using a "central" DBMS for better scaling. I fear this will somehow 
bite itself in the tail. If you have a larger cloud of mail servers that 
means you also have a *lot* of mail traffic and you were required to 
cluster it to cope with that. Now going to a single DBMS backend means 
"re-introducing" a single point of possible slowdown and failure. So, I 
rather think that any managing improvements coming with a DBMS backend 
will mostly apply for *smaller* mail clusters.

Maybe I'm missing a few points of this thread but this is what comes to my 
mind about it at the moment.

As I'm only using milter-greylist for "normal" greylisting my arguments 
may not apply too well to other uses, like blacklisting or whatever else 
can be done with mitler-greylist nowadays.


Kai

-- 
Kai Sch\ufffdtzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com