[Mailman-Users] Bounce issues with Yahoo

[Brad Knowles]

At 2:55 PM -0800 2006-03-02, Harold Paulson wrote:

>>  	How could the MTA possibly know that the MLM would choose to reject
>>  those messages because the sender is not a subscriber?  Or that the
>>  MLM might choose to hold those messages for moderation, because the
>>  sender is not a subscriber.
>
>  Better MTAs can do this.

	I've been specializing in Internet e-mail for over a decade, I 
was the comp.mail.sendmail FAQ maintainer for years, I was heavily 
involved in the postfix community from back when it was still being 
called VMailer, and I have yet to run into any MTAs that can do this.

	Please provide evidence for your claims.

>>  	The policy you are proposing is null and void, because the software
>>  in question is not physically capable of acting in the manner you suggest.
>
>  You have the sender and the recipient right at the beginning of the
>  SMTP transaction.  Check a map to see if it's deliverable.  Mailman
>  already maintains such a map.  You just need some glue.

	That would be nice, but Mailman does not, in fact, maintain such 
a map.  It has a procedure that it goes through to determine if the 
user is a subscriber or should otherwise be moderated or the message 
should be rejected, but there is no easy "map" for this process.

	Try checking the Mailman source code.

>  Check out:
>
>  	http://www.postfix.org/SMTPD_POLICY_README.html
>
>  for instance.  There are already policy servers written in Python, one
>  could use as a starting place.  I'll bet a Python hacker could write a
>  mailman-subscriber-checker in very short order.

	Saying that it would be possible to write such a beast is not the 
same thing as saying that such things already exist, and that people 
should configure their software to use the pre-existing functionality.

	That's a very cheap shot, frankly.

>  Surely other MTAs give admins a way to make decisions during SMTP as well?

	Sure, anyone can write an SMTP or LMTP-like engine that 
internally goes through the processes that the MLM would normally go 
through, and be able to provide that information to the MTA through a 
proxy service, but the MTA would also have to be configured to hold 
the sender open while checking the proxy -- again, most MTAs are not 
configured to do this, and for lots of good reasons the MTA authors 
suggest in the strongest possible terms that you not make the mistake 
of configuring their software in this way.

	At the very least, if you hold open the sender like this, you run 
the serious risk of violating the "minimize acceptance delay" 
requirements of RFCs 1123 and 1047.  Yes, I know these are really old 
RFCs, but they are just as valid today as they were on the day they 
were published, and RFCs 1122 and 1123 still comprise STD-0003, which 
is a required Internet standard.

>  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.

	Once you've done that, you'll have the right to encourage people to use it.


	But again, this is an MLM problem, not an MTA problem.  And you 
shouldn't be chastising people to make use of a supposedly 
pre-existing functionality that does not actually exist.

-- 
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/>.