Chris Lewis wrote:
On 11-10-18 03:42 PM, Daniel Feenberg wrote:
As I understand it, some grey-listing systems match on sender/recipient
pairs (not MTA) so as to not penalize clustered outbounds that share
queues.
There's all sorts of 'optimizations'/variations that you can apply for
different behaviours.
You're right, _just_ the MTA would work just about as well for the main
use case: bot armies. But that's not the only potential use-case.
There is a danger in specifying the precise details/tuning values of a
"standardized gray listing" mechanism. If it's too predictable, you
could probably come up with a simplistic mechanism for defeating it
without requiring the complexity of queuing. "Hybrid vigor" is a good
thing.
I think I agree with most you said. Maybe not all.
Greylisting is there and it will exist for some time. There are good and bad
variations/optimisations, good and bad software configurations... This BCP should not generalize
saying that all greylisting is bad, even if some people are tempted to say so.
It seems to me that this BCP mention only problems caused by the filters.
What's still lacking in the BCP proposal is a section about the behaviour of senders MTAs, which,
IMHO, causes a lot of problems too.
Some examples of bad things which really causes problems to greylistings :
* Some MTAs from some (big) ISPs, which connects 3 to 5 times within some seconds and try again only
after some hours (some equals something between 4 to 24 hours).
* Some ISPs using a pool of sending MTAs which IP addresses are randomly distributed over ranges
without any common part. Something like 193.xxx.xxx.xxx followed by 67.xxx.xxx.xxx...
* Some sender MTAs which begins retrying each some seconds (1 to 10) during some days, and ends
being catched by some rate limit mechanism.
* Some bad configured or misinterpreted 4xx reply code
* ...
--
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg