>It is one retry every DELIVERY_RETRY_WAIT (default one hour) for DELIVERY_RETRY_PERIOD
>(default 5 days) before giving up and returning failure. Granted, this is perhaps 719
>unnecessary retries, but is far from "infinite".
Thanks for looking at this!
It's definitely possible I'm just being an idiot here, but
DELIVERY_RETRY_WAIT doesn't seem to be working properly. Mine was
retrying nonstop, and I had tens of thousands of delivery attempts
before I stopped it.
A grep of the code indicates DELIVERY_RETRY_WAIT is defined in
"Mailman/Defaults.py.in" but not used anywhere.
"Mailman/Queue/OutgoingRunner.py" has some code that is trying to check
the "deliver_after" time of a message, but that never gets set anywhere
I can see.
Is the code perhaps supposed to set a message's "deliver_after" to "time
+ DELIVERY_RETRY_WAIT" after a failure?
But you're right that it would have eventually stopped by itself after
five days, now that I look more closely at the code. My apologies for
the hyperbolic description.
>Also note the problem of an oversize digest can be entirely avoided by setting >digest_size_threshhold to a reasonable maximum.
I agree. It *was* set to a reasonable default for the list in question,
and then the list owner changed it to 0 for some reason. Grrr. I may
have to patch our copy to prevent this. Perhaps there could be a
mm.cfg.py option that allows site administrators to limit the maximum
size that can be set, and prevent setting it to 0?
>Finally. consider what happens if this is considered a "hard bounce". It means every
>innocent digest member whose ISP rejects the oversize digest with a 552 will record a bounce
>for that digest. In extreme cases, it could result in users delivery being disabled
>and ultimately unsubscribed through no fault of their own.
Yes, that's a reasonable concern. Of course, the same problem can happen
for many other reasons too (digests rejected for spam, etc.). The only
thing I can think of is that a hard "maximum digest limit" size set to a
reasonable number sitewide would minimize this risk.
However: while searching my logs for how many messages generate a 552
error, I came across this unfortunately common horror:
"host smtp.secureserver.net[68.178.213.203] said: 552 5.2.0
Uczf1w00J3GnVuQ01 - Uczf1w00J3GnVuQ01czf95 This message has been
rejected due to content judged to be spam by the internet community
IB212"
This is an awful abuse of the SMTP standard; it means that removing the
magic "treat 552 as 452" code would trigger bounces in cases like this.
So perhaps this bears more thinking about.
Or perhaps the solution is simpler: When DELIVERY_RETRY_PERIOD is
reached due to repeated 552 errors treated as 4xx errors, it looks like
Mailman currently discards the message without incrementing the bounce
count. Perhaps the code should maintain that special "don't increment
the bounce score" treatment of 552 errors, but not retry delivery of the
message?
Or perhaps this is all irrelevant and the real problem is merely that I
noticed high CPU usage on a server because DELIVERY_RETRY_WAIT is
broken, and fixing that would make me and others neither notice nor care
about the 552 thing.
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/558128
Title:
remove 552 exception for SMTP perm/temp
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/558128/+subscriptions
