Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations

[Hector Santos <[e-mail]>]

On 2/3/2014 1:14 PM, John Levine wrote:

>> There are various other milters that support greylisting; I don't know about
>> their capabilites.
>
> My greylister calls out to a daemon, which just returns one bit,
> accept or softfail.
>

Keep in mind there are two parts to this:

    1) Helping OTHER systems improve delivery,
    2) Helping YOUR system improve delivery.

For #1, you can do this by changing your response to include a fixed 
blocking time related to your GreyList mfilter setup.  This is mostly 
an administrator, sysop level work requirement.

For #2, that is more software work on the sender-MTA where you 
parse/extract the time hint, if any, from the temporary reject 
responses and pass that TIME to your MTA Send/Queuing logic and 
algorithm.  So this requires code change most likely, code developers, 
systems folks, even administrators.

Except for the response template change, it wouldn't have anything to 
do with a GREYLIST mfilter, shim, callout, blackbox true/false 
process, handling of incoming calls.  It is about the mail sender who 
is getting hit with other greylisting server forcing delays.  Its 
about improving SENDER QUEUE/RETRY LOGIC and minimizing delivery 
delays in dealing with a current reality and wide existence of 
Greylisting Servers.

All good and practical ideas to consider if delays is something you 
wish to address associated to forced temporary reject block delays.

Most systems have a progressive retry logic where delays increase or 
vary with more tries.  This proposed method has proven to shown over 
time to reduce all delays to the bare minimum number of retries which 
is two with no extra time delays than necessary.

> I couldn't implement this even if I thought it were a good idea.

Your reasoning would be insightful.

Would there be a technical problem, a security problem and/or 
feasibility problem?

-- 
HLS