|
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.
--
HLS
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-control/).
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:
text: http://www.ietf.org/internet-drafts/draft-santos-smtpgrey-01.txt
html: http://tools.ietf.org/html/draft-santos-smtpgrey-01
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.
==
HLS
|
|