[Top] [All Lists]

Re: SMTP delivery orders - greylisting

2006-11-27 20:55:13

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

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.


Hector Santos wrote:
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

Hoi folx,

Case 1 - 4xx errors
Case 2 - connection failure


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.


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.


<Prev in Thread] Current Thread [Next in Thread>