[Mailman-Users] Bounce issues with Yahoo
brad at stop.mail-abuse.org
Fri Mar 3 12:26:51 CET 2006
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:
> 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/>.
More information about the Mailman-Users