Chuq Von Rospach <[EMAIL PROTECTED]> writes:
> Which ties back to the original problem. Those "warning"
> not-really-bounces are anachronisms of the days when all this was tied
> to UUCP. Basically, they should die. the only way you convince sites
It doesn't really matter *why*, by god. The fact is they are
here, they are in the RFCs and we should bloody well deal with
it. The DSN RFC specifies that warnings exist, and we should be
treating them as warnings, not as errors.
If we don't want delay notifications, then why are we not
specifying "NOTIFY=FAILURE" when sending the message to the MTA?
(ESMTP "NOTIFY" commands are supposed to propagate down the line
whenever possible.)
RFC 3461, Page 7:
"For compatibility with SMTP clients that do not use the
NOTIFY facility, the absence of a NOTIFY parameter in a RCPT
command may be interpreted as either NOTIFY=FAILURE or
NOTIFY=FAILURE,DELAY."
Don't blame the MTAs for doing what is *defined* as correct and
acceptable.
(BTW, we should consider using ENVID [perhaps in addition to
VERP], if we want some help processing bounces.)
All this bitching and whining about not wanting to cope with the
errors/warnings we get back ("*wah* it's *hard*") is a little
ridiculous when we haven't even made a cursory effort to ask for
only the ones we care about.[1]
Darrell
[1] yes, not all MTAs will honor it. so what? If we're actually
making an effort then the "all bounces are fatal" contingent
might have a point, but not until then.
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
