--On 7 June 2006 09:20:46 -0400 Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 6 Jun 2006 22:02:44 -0700 > Mark Sapiro <[EMAIL PROTECTED]> wrote: > > Ian mentioned that he thinks we should change "Reject" to "Bounce", but > I'm not sure I like that. Rejecting a message or a subscription > request is the action that the admin takes. OK, i'm talking about messages here, not subscription requests. As I understand the terms, a "reject" is an SMTP response to a remote server (or MTA) trying to send email. It means "I'm not accepting this email, you choose what to do with it". The sending MTA may choose to generate a DSN, and a DSN that reports a hard (5xx) rejection is often referred to as a bounce message. With Mailman, rejection isn't possible. We've already accepted the message and queued it. When a Mailman list rule, or an administrator decides to "reject" a message, in fact they're choosing to send a DSN bounce message. There's a REALLY REALLY REALLY important difference in the case of spam. Most spambots will ignore a reject and NOT generate a DSN bounce message. However, if you choose to bounce the message, then a DNS will be sent to an innocent third party. That's collateral spam, and it's a nightmare. Unfortunately, RFC2821 says that you must generate such collateral spam, and that's why I want my MTA to be able to read Mailman's config - so that it can reject email properly at SMTP time. > Mailman's response to > that rejection is return the original message wrapped in a response. > The term "bounce" to me implies a more automatic return that happens at > a lower level in the mail stack, and it might be confused with > terminology in the bounce processing u/i. > So I think the following terms should be used consistently (I'm not > suggesting a mass rewrite to adhere to this): > > Approve > Hold > Reject > Discard > > - -Barry > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iQCVAwUBRIbSsXEjvBPtnXfVAQKejwP/QPSup6mVwOezrMdYKly73z3QH3kbq3MN > pzUanylMlhZ9mVB1AYfLLnqI4/ziWmNjkPRj31VtrGKVnTBGHLGAYCnmFB8E4S/P > Zk5DvyG3fPj3VNCfFDN/UyKbaWMIe4tv7qHnS2C5xgE+pIBm00PPtmh9F0INElEi > DwxEI348tIU= > =b6Qu > -----END PGP SIGNATURE----- > _______________________________________________ > Mailman-Developers mailing list > [email protected] > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a > c.uk > > Security Policy: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp -- Ian Eiloart IT Services, University of Sussex _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
