[Top] [All Lists]

Re: We need an IETF BCP for GREY LISTING

2011-10-25 11:21:38

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 

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.


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?


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