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@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):
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.
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.
- 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