Paul Smith wrote:
On 26/10/2011 16:22, John C Klensin wrote:
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.
The reason why I don't think this is an issue, is that spammers already
have the information they need to get around greylisting.
Right, the 4yz retry code.
'retry=<time>' data won't give them any information they need to be able
to get their messages through. However, the fact is that, for now at
least, many are not doing anything about countering greylisting. When
they do decide to do something about it, the 'retry=<time>' data won't
be vital to them, or even make their job significantly easier.
+1. There is basically two categories of senders GL addresses:
1) Primarily those that will never retry for whatever reason that may
be. They just don't. However, one can reasonable suggest Spamming a
low margin, high volume market business and success is measured in low
acceptance rates such as 1% or even less. So randomly blasting 1
million harvested email addresses and getting 1% (10,000) is often
deemed successful in this market. I still see 1990's address for our
usage base when we offered Free accounts to customers. We also see
many CIS (CompuServe) email addresses still being tried. And a huge
amount try obscure variations user-ids in addresses.
2) Secondary are those that do retry, but they retry again maybe twice
more immediately and often using a different IP. Even with a low GL
blocking time such as ours with 55 seconds, I see these getting
blocked again and stop after the 2 to 3 fast retries.
With #2, it is also apparent many that do have fast retry will back
off and retry later and GL can not stop any client that retries after
the blocking time.
But it is #1 which is by far the major benefit of using an intentional
4yz temporary rejection methodology for mail filtering anonymous senders.
Having said that, I'd prefer the 'retry=<time>' extension to be generic,
and not linked to greylisting, except by coincidence.
The problem with going generic will depend on what we mean by
"Generic" and how broad we want that to be.
Ideally, in my technical opinion, from a pure mechanical client/server
state machine protocol framework, it can be a very simple generic SMTP
concept or generic SMTP extension to the 4yz response. We could
SMTP Extension for Handling 4yz Temporary Rejections
The abstract may say:
SMTPRETRY is SMTP extension to provide retry time delay
information in negative temporary rejections 4yz responses
to help address issues related to wasted attempts and
delayed mail delivery.
With a very simple implementation description with no subjective
background reasoning for why the SMTP 4yz exist in the standard or why
servers use it, it can simple define:
A server MAY add a retry=time-delay in in 4yz responses and
clients MAY leverage the server time hint in the client
retry framework employed in their implementation of SMTP.
So this would be simple generic idea for extending the SMTP 4yx
But if we begin to talk above and beyond that with SMTP Traffic
Control and Management ideas then IMO, it gets more complex and begins
to introduce a whole range of things that is not closer to modifying
SMTP protocol and definitely will require more code changes to
implement the more elaborate proposal. What will happen IMV is that
people will pick and choose what they need and chances are good it
will be for "Greylisting" reasons systems are facing today.
SMTPGREY tries to keep a real focus to realistically deliver this
extension with specific existing practical purposes and things that we
can measure today. It is not experimental or a BCP although
documenting the basic GL framework does lends itself to making some
"suggestions." I approached that by simply indicating to keep delays
as low as possible in the name of keeping with timely deliveries and
lowering the impact of intention temporary rejections. I provided some
empirical average values for blocking times. But overall, the
extension is not intended to change the standard SMTP protocol, the
pseudo-standard GL "protocol" and begin to mandate any idea that
intends to change how systems concurrently behave. Its an extension
and by its definition, its all optional and does not alter anything
but to allow a server to tell a client how to handle a 4yz response in
terms of "Time."