At 12:26 PM +0100 2006-03-03, Brad Knowles wrote:
I think the right solution is to reject junk, instead of accept-and-bounce. I think accept-and-bounce is a blight on the internet, that lowers the quality and reputation of email. I think it is a waste of resources.
Fine. Then write the Python code to do all the magic work and contribute that back to the Mailman community, and get that incorporated into an upcoming release.
Note that an SMTPD_POLICY daemon is not going to be enough. There are things that Mailman can do based on the content of the body, or based on what the anti-spam filtering system has done to the message, so having just the envelope sender and recipient information isn't enough.
To make this work right, what you're going to have to do is write an LMTP delivery interface for Mailman, so that you have Mailman go through all the appropriate steps of handling a message based on the envelope, header, and body content, meanwhile keeping the MTA open the entire time. Your alternative is to write an SMTP proxy interface where your code goes through all those same processes but then throws away the result after it passes the return code to the caller -- if you're going to go through all that work anyway, you might as well save the result and go ahead and deliver the message.
See <http://www.postfix.org/CONTENT_INSPECTION_README.html> and <http://www.postfix.org/SMTPD_PROXY_README.html> for examples of doing this as an SMTP proxy instead of an LMTP delivery interface, but note that all the performance issues are going to be the same. Let me quote:
external, medium-weight, real-time
This method inspects mail BEFORE it is stored in the queue,
and uses the SMTP protocol. Although this approach appears
to be the more attractive one, it really combines the worst
of the other two. Because mail is inspected before it is
queued, content inspection software must finish in a
limited amount of time, and must run in a limited amount
of memory. If content inspection needs too much time then
incoming mail deliveries will time out, and if content
inspection needs too much memory then software will crash
under a peak load. Before-queue inspection limits the peak
load that your system can handle, and limits the
sophistication of the content filter that you can use.
Details are in the SMTPD_PROXY_README document. This
approach is available only with Postfix version 2.1 and
later.
Moreover, an SMTPD_POLICY daemon would be a postfix-specific solution. An LMTP delivery engine would be a generally applicable solution which could be applied to any MTA that supports LMTP.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See <http://www.lopsa.org/>.