Re: We need an IETF BCP for GREY LISTING

Patrik wrote:

> On 25 okt 2011, at 15:29, Hector wrote:
>
> > > If this became an RFC, which I object to, I immediately would hack my smtp
> > > server to lie, because only real smtp clients would probably retry enough to 
> > > get the mail through.
> > Lie in which way?
> By saying "you are gray listed in 5 minutes", but in reality the gray list is 7 
> minutes.
But that is exactly whats going on naturally. The MTA is blind and has 
its own retries that is either too low or too high than the actual 
blocking time.
If the SMTP server is going to lie about it, well, we might as well 
give up on everything we do with the notion that its possible anyone 
can lie about anything.
In my view, we go into these things with a positive expectation 
keeping insight on real negatives that can occur.  We are talking 
about a compliant, well meaning server.
I also believe if you lied about it, you are not only hurting 
legitimate MTAs (compliant to the Extension or not), but also hurting 
yourself more with more wasted retries connections to your sites.   At 
what point are you not going to lie or just accept the MTA retries? 
When you get tired of intentionally providing false information?  "Ok, 
I had my fun, let him in!" :)
> > > There is even a risk people will require support for this which would limit 
> > > the ability for spam fighters to on server side guess whether smtp flow is 
> > > legitimate or not.
> > How so?
> Because, as in the example above, the one that gray list in 7 minutes while saying 5 
> will not conform to "the RFCs that describes SMTP" and because of that will be 
> rejected in RFPs that require mandatory implementation of it
My response still applies, if you lie, you are hurting yourself more 
with unnecessary retries.
> > The fact is, Greylisting can't address any SMTP sender that retries. It 
> only address the abusive random "single shot" senders that will never try the 
> same transaction again.
> Why?
>
> Depends completely what algorithm is used to finally approve and accept the 
> incoming mail.
The classic Greylist concept is as you originally stated:

     "the whole idea with gray listing is that the assumption is that 
real
      smtp clients are more stable than spam senders."

in short, they will retry with the same transaction.  A secondary 
Greylist feature was the "Blocking Delay" which was to address those 
that do retry immediately or with very short frequencies.
> > > I.e. the draft is not explaining what problem there is to solve, the contrary. 
> > Didn't the background section go into details for the various issues and impact 
> > due to Greylisting?
> No.
>
> It does not explain well enough (obviously, otherwise I would not write this ;-) ) 
> what problem this I-D would solve.
I think the impact statements and solution proposed is very clear. 
None of the reviewers brought this up, but if you have a problem with 
it, it probably needs to be restated anyway.
> I.e. why does it help that someone give the hint "gray listed in 5 minutes" but 
> the gray listing is 7, instead of today when no hints are done at all (in 
> a parseable way)?
I personally do not think this is a reasonable objection for the 
reasons stated above. An intentional lie doesn't do anything more than 
to hurt yourself and probably more so than the MTA.
Nonetheless, it probably should be noted very strongly in the proposed 
spec that a MTA be watchful of liars  who are wasting everyone's times 
with false retry=time hints.

Thanks for your comments

--
HLS