[Mailman-Developers] 2.1.8 documentation mismatch

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 07 Jun 2006 15:46:56 +0100
Ian Eiloart <iane at 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-----