[Top] [All Lists]

Re: new draft: draft-santos-smtpgrey-01

2011-10-26 22:03:12

John C Klensin wrote:

tim kehres wrote:

I've mentioned this to Hector directly, but my feeling is that
while an SMTP extension can be useful, I think tying it to
Greylisting is a bad idea.  If what we're looking for is a way
within a SMTP response to indicate a retry time for the
sending MTA, this can and SHOULD be a generic specification
and not one tied to a single application.   Something along
the lines of what is in the Atkins proposal seems more
reasonable to me

While it might not help significantly, something more generic
would at least slightly and temporarily lower the odds of a
different problem.   I really worry about saying to the spammer
"this site does greylisting" and, if that happens enough, having
the spammer respond (internally) "ah, it is greylisting and not
some random temporary server unavailability, we know what to do
about that".
Independent of what advantages it offers people who are trying
to cooperate in sending legitimate mail, to paraphrase Paul
Vixie, giving spammers the information they need to become
smarter and the incentives to do so are really not in our
long-term best interests.

I have other doubts about both proposals but, if we are going to
move forward with either, I think we need to understand and
consider the tradeoffs very carefully.

I can only make one point here.

We already had a standard SMTP client/server framework where by a temporary negative reply code (4yz) is by design meant to drive clients to retry. I don't believe it (the server) any correlations to when a MTA will retry or if it every will and can only base time would be related to the SMTP standard recommendations for retrying - hence an expectation there will be new attempts. If we did not have the confidence that a 4yz will do what it meant to do, I don't believe we would have had the success over the years as a working mail system short of always accepting a payload and have a much different client/server paradigm of mail transport, acceptability and delivery.

My point is that adaptation has already taking place and any "bad guy" that wanted to get around the idea of "Greylisting" long had the ability to do so already simply by following the 4yz concept independent of any server reason for the rejection.

The real impact of Greylisting is the how its attribute of a "Blocking delay" has an affect on the theoretical and empirical protocol impact on the standard SMTP retry framework.

Greylisting address the market problem of senders that seem to be using a bulk volume of random addressing blasting with the goal of achieving by some measure of success, a 1% rate of accepted mail the first time. This is a low margin high volume market and I venture due to cost reasons, it doesn't pay to waste too much time on transactions that are rejected. But I am sure the more professional outfits have the better eMarketing tools and these spammers can not be controlled using temporary rejections simply because they do use standard SMTP software, probably the top free ones out there that already have all the intelligence built in.

Yet, lets suppose that the highlighting of a new standard extension exposing how clients can lower the impact of temporary rejection filtering methods, the question is what are the pros and cons here:

   PRO:  Good Guys Benefit
   CON:  Bad Guys Benefit

I just find it hard to believe that an "Standard' to exposed server hints is going to have any negative effect with bad guys adapting since it has already taken into account GL is ineffective against any client that will retry.

There is no illusion to the idea that the "secret entry ticket" is to retry. Bad guys already know this.

This I believe the PRO of helping the good guys will outweigh any CONS with BAD GUYS suddenly getting an flash of genius insight:

    "Ah ha, so that is how I can get this 4yz sites to
     finally give me a 250. I have to retry again at a
     certain time.  Now if I can only figure out how to
     make this primitive software to retry......."

Personally, I never like to provide more information to SMTP transport level mail filtering rejections than needs be. We had the debate here on the pros and cons of how much information is provide to assist support and/or users, better without "teaching" bad guys why they were rejected.

But I think what is different here is that we already naturally telling the "bad guy" or any client because GL looks at all anonymous senders, how to solve their problem using a standard 4yz response - "Try again later"

Just making the point that 4yz inherently presumes clients will retry and those that didn't already behave using what is already there to solve a problem, I find it hard to believe they will now change to begin reading the hint to finally make them to retry.