[Top] [All Lists]

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

2011-10-26 12:18:31

While in the ideal sense, I fully agree a perfect generalized solution is better, in reality, I believe there are far too many issues here.

First, the primary focus of SMTPGREY is two folds:

   - Formalize the Greylisting Mail Filtering method in how it applies
     in SMTP and also impacted normal standard SMTP operations, and

   - Offer an advanced Greylisting feature to help lower the impact
     it does have on standard SMTP systems.

This is something people can grasp, the "smoke" is there. In this proposal, there are very minor changes necessary to adopt it and it offers a helper "time factor" into a retry/queuing logic that already exist. So the focus is on this one part of SMTP only. Less than a few minutes of code changes and text response change.

On the other hand, when we begin to go general, again, ideal, but now the complexity grows, the scenarios grows - subjectively and the code changes required will grow as well. For example, Atkin's proposal, if I reading it correctly, it leverages the wait= concept for multiple reasons and logics, not just one. One includes an elegant idea to the Connection Sharing/Holding concern where there is a lot of CPU IDLE WASTE time being observed by these Connection Sharing/Holding clients, by using a WAIT=0 to tell the client to hang up. He also introduces what I believe is something radical of using a wait= time for permanent rejection codes (55x), including positive responses (250). This is are very subjective ideas and in my view, beyond the scope of the central wasteful attempts/mail delays issues. Its definitely more than what I seek.

Further, SMTP Client/server drives each other. The client sends commands to move the server into its states, the server drives the client with its reply codes.

Greylisting and the SMTPGREY does not deviate from this basic concept. With Atkins, a server can issue a WAIT=0 to tell the client to hang up, but will large volumes and/or connection sharing agents do so? In other words, harder to control and you may end up doing what we did; shortening the Idle time after the first transaction has taken place. This has provided a huge savings in CPU IDLE waste time.

Lastly, with a full blown more generalize doc, changes are good it will not be a broad enough to cover all sizes of the market and would cater to the "Rough Consensus" of the larger systems. It can end up where an implementator nitpicks parts of the generalize spec. I am talking both as a server and client implementation, where you taken a chance of being accused of non-compliancy if you use one part for a client need but not another part for a server need, etc. Again, there is no guarantee one will listen to a WAIT=0 to make them hang up - one way to guarantee that. Drop them, hence this part has lesser enforcement value. With a specific focus with Greylisting and 4yz, there is more focus and control.

So yes, if it can be done in general with open mindedness to address all parties, great, true open house, etc, sure, but unfortunately, I have my doubts it can be done with losing the rest of my hair.


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 (

Best Regards,

-- Tim

----- Original Message ----- From: "Hector" <sant9442(_at_)gmail(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, October 26, 2011 10:04 PM
Subject: new draft: draft-santos-smtpgrey-01

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title           : SMTP Service Extension for Greylisting Operations
Author(s)       : Hector Santos
                          Evan Harris
Filename        : draft-santos-smtpgrey-01.txt
Pages           : 18
Date            : 2011-10-26

   GREYLIST is a SMTP extension to formalize the widely supported
   Greylisting mail filtering method and to help support SMTP rejected
   transports by following a new formal structured 4yz server temporary
   rejection response by including a "retry=time-delay" tag string which
   SMTP clients can use to optimize the rescheduling of the mail
   delivery attempts.  With adoption, network overhead reduction in
   wasteful mail delivery attempts will be realized.

A URL for this Internet-Draft is:


I would like to extend my grateful appreciation to the interested parties, onlist, offlist and lurking members of the Greylist-user support group, who provided input and assisted with the new draft. Thanks.