[Greylist-users] Waiting until after the DATA phase.

[Corey Huinker]

> There is also a practical reason. With exim, its *easy* to handle it after
> DATA, but I haven't found a good way without major programming surgery to
> splice in greylisting after RCPT.

Sure, there's always the easy route.

> If mysql had stored procedures (which are supposedly coming in mysql
> version
> 5.0), it might be possible to put all of the greylist logic in the
> database
> and use exims general database query to implement it.

Don't hold your breath.  I did an informal interview of the mysql
developers back in early 1999, for an article in a now-defunct online geek
rag.  They said stored procedures were "about 9 months away" back then. 
48 months later, we're still waiting.  They made a similar promise for
implementing views and subselects, and I'm still waiting on those.

Now, switching backend DBs is certainly an option.  The stored procs are
possible today in Oracle, SQLServer, DB2, PostgreSQL, etc.

Heck, just normalizing the db (something Evan avoided for clarity in the
reference code, but clearly wants in a real-life implementation) would do
wonders.  For instance, you could split out sender and recipient emails
address es into their own tables.  If you don't find the sender's address
in the new sender_address table, then you know this is a first time
receipt, and you can just blindly do your first-time inserts, knowing that
you couldn't possibly have seen this email before.  I'm oversimplifying,
of course, buy you can see where major parts of the greylist check can be
short  circuited.

> But right now, using the existing version of exim and mysql, I don't see a
> good, simple way to implement greylisting in exim after RCPT.

Right now, there probably isn't.  I'm not faulting you for putting it
post-DATA, I just wanted to remind people that there is a tangible benefit
to doing so pre-DATA, which none of the big filters (spamassassin, etc)
can do.  Bob, Evan and I had a pretty good conversation about the
estimated bandwidth savings.  We anticipated a resistance to
implementation based on admins being afraid that they were essentially
doubling their email bandwidth.  Our bar-napkin SWAG (scientific wild
a**ed guess) figures showed that the bandwidth costs stayed the same even
if valid emails retried NINE times before being accepted.  Anything less
than 9 retries was a net savings of bandwidth for the greylister.  Evan
may have refined those numbers since then.

Greylisting is a strange duck in that it ideally fits in the filter chain
after valid-user and dnsbl checks, but before body checks.  And so far,
only sendmail is architected to allow for that.