Yep, but there are also MTA behaviors that are *not* so easy to
demonize that also prevent efficient delivery when they encounter
common greylisting implementations.
One is the shuffling of outbound mail across servers in a mail
delivery farm during the retry interval. As a result, the source IP of
each attempt, and thus the triplet, is different.
With inferior greylisting, but not with postfix postgrey, which masks
the last octet of the sending IP, so a triplet retried from a ClassC
is accepted. 3 distinct triplets (or whatever the threshold is set
to) from the ClassC automatically whitelists the IP and/or ClassC.
Another is the use of MXs that do not share the same greylisting
database.
SQLgrey is based on/forked off postgrey. MXs running SQLclient work
into the same external SQL database.
A third is really human behavior, not MTA behavior. It's a basic
imbalance between the size/entitlement/respect of the sending side of
a business relationship and the receiving side. To say that the
expectation of first-time delivery is a mistake to be corrected by the
sender (when you ask why the senders aren't "retrying in less than 12
hours, in the first place") is wishful thinking.
nor at all. with retry window set to 5 min minimum - 12 hours,
median retry is well under 1 hour, which huge spike around 15
minutes. And in case somebody isn't following, that one retry gets
the triplet/ClassC greylist-whitelisted for 30 (or more days). The
vast majority of sender NEVER see the greylisting delay at all.
If I'm a small mutual
fund provider and I want Charles Schwab to sell my funds, sorry,
Schwab has every "right," such as it is, to be on a 2-, 3-, or 4-hour
retry interval because of their status in the industry and huge
volume.
If Schwab wants their incredibly important email to be timely or as
fast as real-time chat,
then why would they set their outbound retry to 4
hours? (rhetorical, don't answer)
The mail admins at Schwab, or any mail admin in a business seriously
dependent on timely mail delivery (nobody can guarantee mail
delivery, and esp not timely mail delivery), obviously have by now
encountered 1000s of MXs doing greylisting for over a year now, and
THEY know how to fix THEIR problem of stupidly long retry.
If a mail admin has problems with greylisting the entire Internet due
to pathologically stupid senders, then it's very easy to restrict
IMGate greylisting to classes of IPS, such as IPs without PTR, IPs
whose PTR matches "subscriber access" network PTRs, etc.
I haven't been asked to do it since greylisting just hasn't been a
problem for my (very high volume) clients, but before turning on
greylisting, one could harvest for, eg, 2 weeks, the IPs that
successfully sent mail through the gauntlet of all other filtering
and dump them into the greylist whitelist database. The same
pre-production period/harvesting also works great for SAV, which
itself can be restricted to classes of IP as above.
Another tactic is to harvest and whitelist the IPs of MXs of outbound
mail (assuming the outbound mail is guaranteed legit).
Greylisting in general isn't the nightmare you make it out to be,
and there are easy ways to anticipate and reduce the mild, extremely
short, one-time discomforts to nearly zero.
Len
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
