Milter-greylist

Moritz Both <mb@...> wrote:

> So nobody said delaying until after the DATA phase if the sender is null
> is a bad thing. Happy to be able to contribute easily, here is the patch
> against 1.6 (I havn't tried the development versions because production
> is my goal and of course this patch is bug free). Do with it whatevery
> you want...

Reading your code, I remembered why this was a difficult problem. Think
about this kind of scenario:

greylist.conf contains this:
acl whitelist rcpt john.doe@...
acl greylist default

Here comes a message:
addr 192.0.2.13, from <>, rcpt someone@...,john.doe@...

When you see someone@... you tag it for rejection after the DATA
stage, so you answer OK.

When you see john.doe@..., you just accept the message, you
answer OK.

Then you reach DATA. What should we do? 
1) Sending TEMPFAIL now will cause the message to john.doe@...
to be delayed whereas john.doe@... were not to have greylisted
mail.  
2) Sending OK will cause the mail to someone@... to pass through
whereas we wanted to have it greylisted.

I'm not sure what your code will do (can you tell it? :-), but anyway it
is bound to badly address this scenario as none of the two alternative
are satisfying.

How should milter-greylist behave in such a situation? As we have to
choose between two broken behaviors, I wonder if there shouldn't be a
config knob to select between the three behaviors when receiving a mail
from <>:
- don't wait DATA stage, do the TEMPFAIL or OK at RCPT stage
- wait DATA stage but fallback to TEMPFAIL if RCPT stage lead to
incompatible results.
- wait DATA stage but fallback to OK if RCPT stages lead to incompatible
results.

Something such as:
delayed_reject (no|fallback greylist|fallback whitelist)

Opinions on this topic?
 
-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...