[Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing

[Ian Eiloart]

I'm taking this back on list, since I think the principles are relevant to 
Mailman.

--On 10 August 2006 17:07:48 -0700 Jeff Schnitzer <jeff at infohazard.org> 
wrote:

> Ah, you want to reject /senders/ at SMTP time, not recipients.  Ignore my
> last message.
>
> There's no reason why SubEtha can't bounce mail from unknown senders.  It
> would not be difficult to do*, and may show up in a future release.
> However, it's not the universally appropriate solution.

Yes, I know. I filed a bug report, and was told it was a feature not a 
problem. That's when I stopped considering using the s/w. This was a couple 
of months ago. If the situation changes, then it would be worth considering 
again.

>  I see three
> different solutions to this problem (mail from unknown recipients):
>
> 1) Reject it at SMTP time.  Legitimate senders are notified that their
> mail was not delivered but there is no opportunity to auto-moderate the
> message or any opportunity for list administrator to moderate the
> message.  Great for spam rejection though.
>
> 2) Hold the message and send the envelope sender instructions to
> auto-moderate.  Very friendly to legitimate users but bad for the
> recipients of joe-jab attacks.  However, using SPF makes this a
> non-issue.

I'm not anti-spf in principle - unlike Brad. However, it's not widely 
deployed so it can't be relied on in this case.

> Using this on a relatively isolated network or behind heavy
> spam control makes this a non-issue.

Well, there wouldn't be much point putting an MLM server on an isolated 
network. Not for us, where inter-institutional collaboration is very 
important.

> 3) Hold the message silently, sending no instructions for
> auto-moderation.  This is not so friendly for legitimately confused users
> whose messages go into a vacuum, but the ideal circumstance for
> announce-only lists which *always* moderate all messages.  Of course,
> this is just fine for spam control.

Yes, that sucks, but that's where we're left with Mailman. In fact, it's 
one of the main reasons I'm looking for a MLM that does (1). I can't think 
of any case in which (3) is better than (1).

> There are perfectly legitimate reasons to use any of these 3 approaches.
> We started off with #2, and will probably eventually accommodate all
> three.  I'm sorry if it's not on a schedule that makes you happy, but we
> certainly do accept patches.
>
> * This depends on what sort of MTA you are using.  If SubEtha is directly
> receiving public input, it's trivial.  If inbound mail is being relayed
> through another MTA, it gets a lot more complicated.  The problem is not
> a design issue in SubEtha, it's the antiquated design of all commonly
> used MTAs.  Anyone who wants to integrate *anything* with
> Postfix/Exim/Sendmail/Qmail and friends will be frustrated - they just
> don't provide easy hooks into the SMTP exchange.

No, it's very easy common to do call forwards with Exim. That would tell me 
when the list won't accept the sender. So, if Brad's right about Postfix 
and Sendmail, that just leaves Qmail and friends. Never mind.


-- 
Ian Eiloart
IT Services, University of Sussex