Re: qmail is officially public domain. have at it lads!

[John Simpson <jms1@xxxxxxxx>]

On 2007-12-07, at 1101, Robert - elists wrote:
> What other factors besides IP are you talking about?

my greylisting implementation makes the decision about whether to  
delay the connection or pass it on, based solely on the client's IP  
address (or the /24 block.) what he was talking about is making the  
decision using the IP (or /24), the envelope sender, and the envelope  
receiver, all as a linked set (a "tuple".) the idea is that if a  
spammer is using 1.2.3.4 and sending multiple messages with multiple  
forged senders, or sending to multiple recipients, each (IP/sender/ 
recipient) would have its own timers associated with it.

my first problem with is is that any given message might have multiple  
recipients, some of which might form a "known" tuple and others might  
not. my inclination would be to accept or reject each RCPT command, on  
the theory that a legitimate sending MTA (such as qmail-send) would  
track which recipients had been accepted and rejected, and retry the  
other recipients later.

anyway. the real issue is that my code stores each entity (IP or /24)  
as an inode in the filesystem, with no data, using the atime and mtime  
fields to hold the "first connection" and "most recent connection"  
data. the code within the jgreylist program uses the "first  
connection" datum to make the decision whether to delay the connection  
or not, and the cleanup script uses the "most recent connection" datum  
to decide when to remove stale entries.

using the filesystem would not be a very good choice for storing the  
necessary tuples in a three-data system, because on a busy server  
there could literally be hundreds of millions of combinations, and  
most filesystems won't have enough spare inodes to handle it.

also, since the sender and recipient aren't known until qmail-smtpd is  
already running, the code to make the "delay or accept" decision would  
have to be inside of qmail-smtpd... and in order to address that many  
potential tuples in an efficient manner, you would have to store them  
in a SQL server or something similar, which means embedding SQL client  
library calls (or any kind of "outside data access" calls) into the  
code as well- something i have always tried to avoid.

this is why i wrote the validrcptto.cdb and auth.cdb patches to use  
cdb files- the code needed to find data within a cdb file is already  
present in qmail-smtpd. however, cdb files don't work very well for  
data sets which change constantly.

i had thought about using something like gdbm or berkeley db files for  
a greylisting back-end store, but i've had concurrency issues with  
them in the past (several years ago), and to be honest, once i found  
another greylisting implementation which used inodes as data storage,  
i wasn't very inclined to dig into it. i don't like having to deal  
with file locking, especially where it's done differently on different  
types of machines.

> Are you sure great delay is RFC compliant?

absolutely.

> Which RFC are you referring to above?

a reading from RFC 2821, section 4.3.1, paragraph 2, verses 1-3:

   One important reply is the connection greeting.  Normally, a  
receiver
   will send a 220 "Service ready" reply when the connection is
   completed.  The sender SHOULD wait for this greeting message before
   sending any commands.

according to section 2.3, the word "SHOULD" means that it's not "set  
in stone", however there needs to be a darned good reason for doing  
something different. in my mind, there is no good reason for not  
waiting, unless the sender is trying to force the mail to transfer as  
quickly as possible- i.e. if they're sending spam.

which tells me that it's closer to being required than it is to being  
prohibited.

the really effective thing for me has been the DROP_PRE_GREET feature,  
where if the client DOES send any data before the server sends the  
greeting, the server sends a 554 and hangs up.

----------------------------------------------------------------
| John M. Simpson    ---   KG4ZOW   ---    Programmer At Large |
| http://www.jms1.net/                         <jms1@xxxxxxxx> |
----------------------------------------------------------------
| http://video.google.com/videoplay?docid=-1656880303867390173 |
----------------------------------------------------------------

Attachment: PGP.sig
Description: This is a digitally signed message part