One other point.
In other latest work, Greylisting support has been in field testing for
almost a year now, but we are still a little reluctant to making it an
official offering to our WCSMTP system. Nonetheless, there is no
disputing the growing popularity of greylisting among our sysops who are
trying it out.
When a GREYLIST receiver system issues a 45x, it wants the other end to
retry again. The GreyList theory works on the basis "Good guys" are
SMTP compliant MTAs and will try again with the same parameters, "Bad
Guys" typically are not and do not try again using the same parameters."
In order to "lessen" the pains of a GreyList System forcing delays in
reception of valid mail or in trying again, one thing we had to do was
offer a more flexible retry frequency table.
By default, our retries were once per hour for the next 72 hours. By
introducing Greylisting, we now have a default freq table of:
; Values are in minutes
[Attempts]
Default=60
Attempt1=5
Attempt2=5
Attempt3=15
Attempt5=30
Attempt10=120
Attempt21=5
Attempt22=5
Attempt23=15
Attempt25=30
Attempt30=120
Attempt40=60
Attempt72=60
What was more important was the initial retries. This help make the
greylisting system more palpable in the area of getting that message
delivery as soon as possible.
---
HLS
Hector Santos wrote:
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
Hoi folx,
Case 1 - 4xx errors
Case 2 - connection failure
Opinions?
Well, I have to say that all of the modern MTAs I've seen have managed
to find
strategies for handling this stuff that work very well in practice, so
the
specifications for this seem to be "good enough". And if it ain't
broke... I
have a hard time believing that it is worth investing the significant
time that
would be needed to "clarify" our specifications in this regard.
+1.
I can add that for our own MTA, we use the connection failure as a
trigger to try the next MX expanded/priority sorted IP list entry. A
4xx will re-queue the message for the next send attempt cycle based on
the admin's local policy frequency table. A 5xx, of course, stops the
transaction attempt altogether and initializes a bounce process.
A few things come to mind:
a) For scalability reasons, there is an inherent presumption that a
receiver farm are just workers for the same remote backend server
serving the target recipient account. So a 5xx/4xx response for one
receiver would yield the same for the other receivers. I think it would
be unpractical to presume that you will get a different 4xx result by
simply going to the next IP during the same message queue attempt. I
think a remove server who believes a MTA will immediately try the next
IP based on a 4xx, is making a wrong generalization.
b) With the help of DNS, for larger MX systems it is prudent they make
sure that a random round robin of IPs are presented for their own sake
of maximizing efficient system availability and throughput.
---
HLS