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