Jeff Macdonald wrote:
If you've looked at the draft, and I mean those besides Murray, what
has kept you from implementing it?
My opinion.
In general, like all things, the good ideas are the ones that solves a
real problem.
The SMTP state machine is already well defined and it required reply
codes to drive the client/server automation. Everything else is just
"candy" like extended reply codes are optional, not required to drive
the C/S protocol and no one can depend on it solely. IOW, even modern
clients must also support legacy server with pure SMTP responses.
So you have to provide a good reason why it should be considered. Its
a matter of technical writing style but I generally like to start with
problem statement and then show why/how the proposed idea can help
address the problem and maybe also add value (i.e. 2 for 1 benefit).
That is why I suggested the text about how it (specific extended codes
like X.8.26) can help resolve some of the negativity behind
GreyListing with advanced Retry methods, but as I mention above, for
X.8.26, anyone with such an advanced retry method, it can't depend
solely on this specific code. You got the original Harris
recommendations of 451 and/or 4.7.1.
Finally, this is a subject of opinions. IMV, the I-D extended
responses are focused for bad guys rejects, not good guys rejects
except for the new X.8.26.
So in general, for my own system, I don't particular like to give bad
guys "clues" why their transaction failed. For false positives, it
can help the support process in a DSN, but for bad guys, its not like
they will listen to them anyway or even get them or maybe redirected
to someone else. They are going to blast away anyway.
So if you can extract how these "bad guy" transaction rejection
responses can help good guys solve a particular problem, more readers
will consider it.
--
Sincerely
Hector Santos
http://www.santronics.com