[Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing

John W. Baxter jwblist3 at olympus.net
Fri Jun 29 19:01:12 CEST 2007

On 6/29/07 7:44 AM, "Rich Kulawiec" <rsk at gsp.org> wrote:

> Two related suggestions.
> (1) LHS (left-hand-side) rules
> Any incoming mail message whose putative sender matches:
> do-not-reply@
> do.not.reply@
> donotreply@
> no-reply@
> no.reply@
> noreply@
> and which is directed to any of the Mailman standard aliases can
> be rejected (not bounced [1]) with SMTP status 550 (extended status
> 5.7.1) since either:
> (a) it's a forgery, therefore there's no point in letting
>    Mailman attempt to emit a reply -- or even in accepting
>    the message to begin with.
> (a) it's not a forgery, therefore there's no point in trying
>    to reply to it.  (Nor is there any point in permitting it
>    to subscribe to a list or send any traffic to one.)
> Arguably, this could be done in some MTAs by configuring rejection
> of those LHS patterns on a per-local-user basis; but I'll argue that
> doing this in Mailman itself would be more useful, since many (perhaps
> most) sites don't use per-local-user configuration (and perhaps don't
> know how).  Moreover, any site running multiple mailing lists would
> need to set this up for every Mailman alias for every mailing list --
> so it seems simpler to handle it inside Mailman itself.
> My guess is that this should be a switchable feature, named something
> like "reject-noreplies".  (Not that I can envision a need to switch it
> off, but I think it'd be more conversative to have that option.)

At least here, this good idea would have to be implemented in the MTA which
receives the message, as the message is not presented to Mailman until after
the receiving MTA has accepted the message (in fact, here, it's not even
presented to Mailman by the same MTA or on the same machine).  Thus
rejection is not possible based on what Mailman does.

(Further, in the present Mailman, the presentation is by pipe, so doing
something like Exim's recipient verification callout doesn't work.)

There have indeed been discussions about making the MTA able to get
information from Mailman in time to do SMTP-time rejection.  It's not simple
to do in the general case.


More information about the Mailman-Users mailing list