[Mailman-Users] Bounce issues with Yahoo

[Brad Knowles]

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 at 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, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.