-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 07 Jun 2006 15:46:56 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
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.
I think that's a good point. What's really happening is that the admin is disapproving the message and returning it back to the original sender. The question is, which term captures that better for non-techies (I think techies will get it either way). To me "reject" is better than "bounce". Has anybody seen any comments on this issue on mailman-users?
Using the term "bounce" here also has the possibility of confusion with the automated bounce processing system.
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.
Right, but we're not talking about an automated process here, we're talking about the actions a list admin will take manually. I honestly don't think it's feasible for a list admin to be managing malware. Ideally, 99% of all malware should be filtered lower in the stack, before Mailman (and the list admin) ever sees it.
Of course, no filter is perfect, so if an admin does see spam, then she has the option of discarding it, which is why that operation has been optimized (Discard all messages marked deferred). Bottom line is that all malware that sneaks through whatever filters are in place should always be discarded, never rejected.
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.
Very soon now I am going to start work on a SQLite backend for MM2.2. If we're lucky, I'll be able to use something like SQLAlchemy or SQLObject which will buy you many other RDBMS's at the same time. Then it's just a simple matter of publishing the schema, right? <wink>
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIcYjXEjvBPtnXfVAQLj+gQAucBdCYrIwrGv1vVws2kvPNDRk3MFoQNY k1VOr2KQEgkqLE7tdkw4JZAMN22KxyCsIvs3TRwEQcrChU/kEySNqVJAZT2+KW5T 8NM4Y2fug53SGdjiv/C6Ig/wg3cXWseBC9+RnZdd/vKOC4XHXl5NM6dujkJn8fWy 7DauaMvv5qY= =ggpj -----END PGP SIGNATURE-----