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
(http://datatracker.ietf.org/doc/draft-atkins-smtp-traffic-con
trol/).
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.
--
HLS