On Oct 28, 2011, at 7:11 PM, Hector Santos wrote:
Steve Atkins wrote:
My point is if like Atkins proposal and might implement it, once you do,
you will be behaving like a Greylisted server.
That's simply not true. Please stop stating that.
Are you saying your proposal offer a server issuing of a "wait=" time with no
server tracking and enforcement?
Yes. It's purely a protocol for the server to communicate to cooperative
clients. I foresee the primary usage to be not enforced by the server,
certainly not on a real time basis, though it's something that would be quite
usable if the server were tracking clients in that way.
Its not be meant to be a negative and it doesn't help with ongoing attempts
to create division.
Any proposal that includes a "time delay" for a client to use, and more
importantly the server will enforce, is 100% *behaving* (keyword) like a
Greylisting Server model. I can't see how you can avoid it.
Actually it's not, but that's a different issue. (Greylisting requires keeping
track of remote clients in some way, so as to treat them differently the first
time you see mail from them. As a concrete example of a server enforcing delays
that's not greylisting consider a mailserver with a database backend, where you
need to take the backend down for maintenance for a few minutes. While the
database is down, the server may respond to any transaction with a 4xx (or even
with a 4xx wait=<number of seconds until the database server comes back
online>). Attempted redeliveries before that will be deferred again.)
The client is doing this blinding. If it encounters a server with this
"wait=" in a 4yz response, its going to have the same MTA software
rescheduling code for supporting any other kind a "retry=" or parsing of the
informal existing greylisting servers with their time hints.
So unless the proposal is not offering server enforcement, it is very much a
Greylisting Model.
It's a traffic management enhancement. It could certainly benefit a greylister,
but it's of broader value than that narrow niche.
Cheers,
Steve