[Mailman-Developers] why treat action: delayed in DSN as an unrecognized bounce?

[Brian J. Murrell]

On Sun, 2004-07-04 at 21:52 +0200, Brad Knowles wrote:
> 
> 	Search the archives.

I did.

> I believe you'll find that the answer is 
> that you (the mailing list administrator) should have control over 
> the MTA,

I do -- to the extent that the MTA gives me that control.

> and if you don't want warnings to be treated the same as 
> bounces, then you should configure the MTA so that it doesn't 
> generate warnings.

To say "in order to not treat warnings as errors, disable warnings" is,
respectfully, silly.  Warnings should be heeded but they do not
necessarily indicate that they should be treated as errors.  Where in
life is it valid to say "to not treat warnings as errors, ignore
warnings"?

> 	But you should search the archives to get the full picture of 
> previous discussions.

You are probably referring to the recent discussion of May 2004.  I did
read it.  It did not seem to indicate any real solution (other than
ignore warnings).

And for mailing list mail, it is _perhaps_ valid to simply disable
warnings, so I did look into how to do this.  I did not seem to find any
way to disable warnings for a given Precedence: level in Postfix.  i.e.
for Precedence: list only, disable warnings, but for regular Precedence:
I do want warnings.

I don't think this changes the fact that MM should deal with warnings
without barfing them out as "unknown bounces".  They are known.  The
code is there to "know" them.  MM just prefers to not deal with them,
which I think it should, even if it's to simply ignore them.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040704/8fbeb5c0/attachment.bin