Jo Rhett writes:

This is not substantive, it's trivial.

*sigh* From the point of view of the release manager, there are no trivial code changes to a release candidate. You are handicapping your advocacy by failing to acknowledge the potential for trouble.

Adding a README.backscatter would be trivial. Would you like to provide it, since you evidently know how to make the configuration changes needed?

In any case, it's hard to sympathize with your claim of urgency. Mark's intention to release 2.1.10 has been known for many months. This proposal comes on the eve of release. Code changes to implement it can, and should, wait for the next release.

Jo Rhett writes:

On Mar 4, 2008, at 6:00 PM, Stephen J. Turnbull wrote:

...

In any case, it's hard to sympathize with your claim of urgency. Mark's intention to release 2.1.10 has been known for many months. This proposal comes on the eve of release. Code changes to implement it can, and should, wait for the next release.

What? I'm sorry, but Mailman has been blamed for backscatter for
like 3 years going now.

If you say so. I first heard of the issue within the last year, and that in the context of bouncing back whole messages. And it wasn't from you.

This problem has been well known for long before 2.1.10 was even dreamed of. I am asking that the developers start paying attention *NOW*.

Nobody has said they should ignore the problem, just that *you* are *way* too late in the process to expect them to stop the release of 2.1.10 for this major change in behavior (I almost certainly would stick with 2.1.9 + patches if this goes in hastily; my users do use those features).

I don't speak for them; they might decide this *is* a showstopper. However, I have to wonder how your Mailman users will feel if you change your AUP, and they discover that the *only* post you've made (according to archive search) before going into BOFH mode is this one:

Fri, 04 May 2007 13:06:34 -0700

I remember a number of threads about backscatter prevention, but I  
don't remember the result.  Perusing the archives isn't much more  
enlightening.   Where are we on this?

In particular, other than removing all but one of the aliases, have  
we made it easier for people to run a backscatter proof list?   
Meaning that all subscribe, unsubscribe, etc are done on the web ui  
and nothing in the server automatically responds to e-mail other than
legitimate list mail sent by subscribers?

I also remember discussions about honoring SpamAssassin headers to  
detect spam.  Status of this?

I see no urgency from you there, it got no response from the developers (shame on them, but these things happen), and you dropped the topic for almost a year.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mar 24, 2008, at 9:37 PM, Jo Rhett wrote:

On Mar 4, 2008, at 6:00 PM, Stephen J. Turnbull wrote:

...

In any case, it's hard to sympathize with your claim of urgency. Mark's intention to release 2.1.10 has been known for many months. This proposal comes on the eve of release. Code changes to implement it can, and should, wait for the next release.

What? I'm sorry, but Mailman has been blamed for backscatter for like 3 years going now. This problem has been well known for long before 2.1.10 was even dreamed of. I am asking that the developers start paying attention *NOW*.

If the problems aren't going to be solved before 2.2, then we're going to put Mailman in the same bin as qmail and say that using it is a violation of the AUP.

Now that there's documentation, I don't think you need to be that
severe. Not everybody needs or wants this particular behavior. Those
that do should now have the information at their fingertips. If
downstream distributions want to change the defaults they are free to
do so.

This simply cannot be changed in Mailman 2.1. For one thing, it's a
major feature change, not a security fix. A security problem would be
something like a cross-site scripting vulnerability or remote root
exploit. For another, pushing back 2.1.10 guarantees that 2.2 will be
delayed because of the extra q/a that needs to happen, etc. This
isn't a trivial change and we have limited resources.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR+lnaXEjvBPtnXfVAQKXCwQAk6y1e4juyw4DAh6XIoYzKdSFzZ4/2h9U 3Ql6dfeU14niMIpJPYlf3qKTECu5aI21q+yAlT8t4yud48aAAgqTMkGPWMQ93T8A OZ8YWUhxMypzkxYIyR/X/W/n3rhthdPY3Y6a13F5NhlATEPwQXuXaIwxaN/m7FSC HxTNcT69OrU= =aWxK -----END PGP SIGNATURE-----

--On 4 March 2008 17:08:52 -0800 Jo Rhett <jrhett@netconsonance.com> wrote:

...

If the former, then you must object to DSNs from MTAs as well. If the latter, that is planned to be addressed in Mailman 2.2.

Of course we object to DSNs from MTAs. No shipping mailserver currently sends DSNs to accepted mail by default. Most of them haven't for like 10 years. And yes, we absolutely ban qmail from use unless the person patches it to the moon to solve its problems.

+1

The one reason that I'm looking for an alternative to Mailman is the lack of adequate integration with MTAs, which means that there is no sensible thing that I can do with suspected spam. What I need to be able to do is reject it at SMTP time, based on list post permissions and other configuations - I need to be able to query the configuration from my MTA (Exim).

Holding for moderation and discarding are not adequate solutions, but holding for moderation by default would be a good intermediate step.

-- Ian Eiloart IT Services, University of Sussex x3148

--On 5 March 2008 18:08:39 -0500 Barry Warsaw <barry@list.org> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mar 5, 2008, at 5:33 AM, Ian Eiloart wrote:

...

The one reason that I'm looking for an alternative to Mailman is the lack of adequate integration with MTAs, which means that there is no sensible thing that I can do with suspected spam. What I need to be able to do is reject it at SMTP time, based on list post permissions and other configuations - I need to be able to query the configuration from my MTA (Exim).

Ian, I think that alternative is going to be Mailman 3 :).

How do you see Exim asking that question? I can see several ways of doing it in Mailman 3. 1) you could call into a Python library that can answer that question;

That's doable, with a perl wrapper around a python script. The question I'd want to ask is "is email address a allowed to post to list b".

2. you could use some kind of RPC such as the REST api that Andrew's been talking about;

I'm not sure whether I could use that from Exim.

3. you could make the appropriate queries directly to the Mailman database, which is based on SQLite currently but can be anything that Storm can talk to.

That's probably the most desirable option from the point of view of efficiency, but I'd need to be querying a database remotely. Preferably one with several replicas. Would LDAP be an option? That's what we currently use for our user authentication. Hmm, doesn't look like it. I guess I could knock up a postgres cluster.

The disadvantage of this over (1) is that I'd need to replicate Mailman's logic in the SQL query.

Is that the kind of thing you want to do?

The ideal thing would be if Mailman had an LMTP interface to accept postings, and could make decisions about accepting mail after RCTP TO.

That way, Exim could make LMTP callouts to Mailman (effectively, the HELO, MAIL FROM and RCPT TO sections of the L/SMTP protocol). If Mailman says, yes I'll accept this message for delivery, then Exim can continue.

Mailman might later reject a message based on other information, like attachment size, but at that point I don't mind bouncing the message. In fact, for list members bouncing is better than rejection because I can determine what I'm going to say.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkfPJ/gACgkQ2YZpQepbvXEQNgCfQqZlZIt6kFyb+2MrQcteth1j q/8AnRqG8QjGqwBR0y/IQpFZMxBeiupW =eR4z -----END PGP SIGNATURE-----

-- Ian Eiloart IT Services, University of Sussex x3148

--On 6 March 2008 13:02:01 -0500 Barry Warsaw <barry@list.org> wrote:

...

The ideal thing would be if Mailman had an LMTP interface to accept postings, and could make decisions about accepting mail after RCTP TO.

MM3 will have LMTP, perhaps as the preferred way to get messages into the incoming queue. I hadn't thought about doing acceptance testing right there, but it's an interesting idea to think about.

Yep, it would be the easiest way to integrate acceptance testing with Exim. It's common for sites to put Exim installations in front of Exchange servers (for security reasons), and do SMTP call forwards to test deliverability.

Thanks!

-- Ian Eiloart IT Services, University of Sussex x3148

Kenneth Porter wrote:

Another approach is to dump the valid users list periodically using a Windows-based LDAP app and then copy that to the OSS front end MTA for validation. Check the MIMEDefang list archives for howto.

A bit off topic, but why not run the LDAP app on the OSS system? Or better yet, have front end MTA to query LDAP (AD) directly.

About the original question, +1 for a more thorough LDAP integration and LMTP.

BTW, we have written a couple of utilities to integrate Mailman with Sun's Messaging Server. Another is an MTA wrapper (MTA/Ldap.py) to publish mailman aliases in an LDAP directory, and the other one is a channel program for JES to feed appropriate messages to the Mailman wrapper. And we also have UtuMemeberships.py to authenticate users with our email address against LDAP.

Is there any public interest for those?

-- Eino Tuominen

Ian, I think that alternative is going to be Mailman 3 :).

So, when is this going to be fixed in Mailman 3?

We have the end of 2022, and this bug from 2008 is still unfixed. I was able to generate backscatter to arbitrary addresses (Envelope-FROM) by sending (Envelope-RCPT) to an eMail address whose localpart is a nōn-existent list and whose domain is a server running Mailman 3 (stock from Debian).

Thanks to this, the list server was just blacklisted by its provider, which is a very unfortunate situation.

So, what can be done about this? Why can Mailman not just generate a list of valid addresses, which Postfix can then use? Ideally even via PostgreSQL to avoid the need for reloads (AIUI).

Thanks in advance, //mirabilos

• Mark Sapiro <mark@msapiro.net>:

Why in your example did Postfix treat the RCPT TO that was not a valid list address differently than any other invalid address in RCPT TO? I.e. Postfix should be rejecting that RCPT TO at SMTP time with "unknown user" or some similar error. What did Postfix do in your case.

This is probably due to an error in local_recipient_maps in Postfix. https://www.postfix.org/LOCAL_RECIPIENT_README.html

-- Ralf Hildebrandt Charité - Universitätsmedizin Berlin Geschäftsbereich IT | Abteilung Netzwerk

Campus Benjamin Franklin (CBF) Haus I | 1. OG | Raum 105 Hindenburgdamm 30 | D-12203 Berlin

Tel. +49 30 450 570 155 ralf.hildebrandt@charite.de https://www.charite.de

Mark Sapiro wrote:

On 11/6/22 14:36, mirabilos mirabilos wrote:

...

So, when is this going to be fixed in Mailman 3?

Mailman does this. Mail to an invalid address does not get delivered to Mailman because the invalid address is not in Mailman's generated

Hmmh. This is part-ish of the problem.

But in this specific case, the problem did persist even after disabling Mailman, and it could eventually be traced to a web frontend called modoboa putting its own, broken, configuration. So, this time, Mailman was not the culprit.

Also, beginning in Mailman 3.3.6, even in unusual configurations where an MTA might deliver an invalid recipient to Mailman's LMTP runner, The runner will reject the invalid RCPT TO during LMTP. See New Features at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.h...

That’s good to hear!

Thanks, //mirabilos

On Mar 17, 2008, at 7:28 PM, Mark Sapiro wrote:

A text change breaks 35 existing Mailman translations, and breaks them

Sorry, yes you are right I forgot about translations.

I'm not talking about DSNs to non-accepted mail. I'm talking about a message that is accepted by an MX, queued and later rejected by the ultimate destination. When the MX gets the reject from the
destination, does it say "oops, I screwed up, I never should have accepted and
queued this message" and just drop it, or does it return a DSN.

Does this make sense, or am I stuck in the 20th century?

If you have an MX that queues mail for someone else and isn't
configured to properly deal with DSNs, then yes, you are stuck in the
20th century.

And yes, if your MX host was on our network (and sending DSNs to
forged senders) we'd ask you to shut it down. ("ask" in non-optional
sense)

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source
and other randomness

On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote:

I still don't get what you mean by "properly deal with DSNs". Are you saying that an MTA should never return a DSN? It should either reject the mail during the incoming SMTP transaction or forever hold its piece?

Yes. And not just me, but a dozen different blacklists. RTFM
"backscatter"

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source
and other randomness

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

Unfortunately this attitude does seem to be catching hold. I was told recently that a secondary MX would have to stop functioning as such because his ISP insists that he have an up to the second list of all valid mailboxes at my site; he's not allowed to relay undeliverable mail to me *ever*.

These days, secondary MXs usually do SMTP callouts to verify whether email addresses are valid on the primary mail server. It does, however, make the concept of a "secondary MX" less useful than it used to be.

-- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen

Stephen J. Turnbull wrote:

Jo Rhett writes:

...

On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote:

...

I still don't get what you mean by "properly deal with DSNs". Are you saying that an MTA should never return a DSN? It should either reject the mail during the incoming SMTP transaction or forever hold its piece?

Yes. And not just me, but a dozen different blacklists.

Unfortunately this attitude does seem to be catching hold. I was told recently that a secondary MX would have to stop functioning as such because his ISP insists that he have an up to the second list of all valid mailboxes at my site; he's not allowed to relay undeliverable mail to me *ever*.

So much for the whole concept of a store-and-forward mail system. :-(

Well, it does simplify the MTA's job. Instead of all that queueing and retrying and such, you just have during SMTP (hold on a minute while I attempt to deliver this to the next hop and return that result to you)*N, a system that doesn't seem to scale well. Either that or you just forget the concept that the originator of a message can ever be informed of a delivery problem.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Mar 25, 2008, at 1:06 PM, Eino Tuominen wrote:

Mark Sapiro wrote:

...

Well, it does simplify the MTA's job. Instead of all that queueing
and retrying and such, you just have during SMTP (hold on a minute
while I attempt to deliver this to the next hop and return that result to you)*N, a system that doesn't seem to scale well. Either that or you just forget the concept that the originator of a message can ever be informed of a delivery problem.

You are missing the point. Of course you can inform of a delivery problem, but only when you really need to do it. Every organisation should know of every recipient within their authority. You should know the recipient if you accept a message for delivery from outside your
domain.

But how would you scale that to the size of say... yahoo? Multiple
data centers around the world, all processing mail for different
domains under yahoo's control... How would one be able to synchronize
all that data from tons of different places like that?

-- Eino Tuominen

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/japruim%40raoset.c...

Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

--

Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com japruim@raoset.com

On Mar 25, 2008, at 10:10 AM, Jason Pruim wrote:

But how would you scale that to the size of say... yahoo? Multiple data centers around the world, all processing mail for different domains under yahoo's control... How would one be able to synchronize all that data from tons of different places like that?

Your disbelief has no relevance. Yahoo does do it.

More to the point, I solved this problem for the Navy. 2.5 MILLION e- mail accounts, and they needed to stop accepting e-mail for accounts
which didn't exist.

To put this in perspective, I did this on a 386/25 processor with 16
megabytes of main memory in 1992.

It's not a hard problem, and *every* modern mail system handles this
properly.

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source
and other randomness

On Mar 26, 2008, at 2:30 PM, Lew Wolfgang wrote:

Jo Rhett wrote:

...

More to the point, I solved this problem for the Navy. 2.5
MILLION e- mail accounts, and they needed to stop accepting e-mail for accounts which didn't exist.

I assume you're talking NMCI. I just tested this by sending to a
bogus NMCI address from .com and .mil (non-NMCI) and in both cases the bogus messages were accepted by NMCI. This has always been a major issue
with NMCI and has caused many problems. Good for you if you fixed it,
but it still seems to be broken from my end of the Navy.

I have no idea who NMCI is. They might have changed acronyms. At
the time it was Navsea, SEA-05 (and SEA-04 administration). It was
also a ccMail gateway. My god, I hope they aren't still using that ;-)

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source
and other randomness

On Mar 25, 2008, at 10:59 AM, Mark Sapiro wrote:

Eino Tuominen wrote:

...

You are missing the point. Of course you can inform of a delivery problem, but only when you really need to do it.

That's not what Jo Rhett seems to be saying at <http://mail.python.org/pipermail/mailman-developers/2008-March/ 019928.html>.

If you reject the mail during the SMTP phase, and it came from a
legitimate sender, their mail server will return the DSN back to the
sender.

If it was spam, the spambot will go somewhere else.

This is why you reject during SMTP session. Because if you don't,
the spambot comes back to your supposed legal recipient and sends a
bunch more forged mail. And each of those messages you bounce back
to the innocent victim of forgery.

Now that basic education is out of the way...

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source
and other randomness

Stephen J. Turnbull wrote:

Eino Tuominen writes:

...

You are missing the point. Of course you can inform of a delivery problem, but only when you really need to do it. Every organisation should know of every recipient within their authority. You should know the recipient if you accept a message for delivery from outside your domain.

Says who? There is nothing in the standards that says so. And if you

The times, they are a-changing... We are facing a new world and old habits are not the best ways to do things anymore. I'm certainly not one of those deeming all DSN's as evil, but it really hurts our users when some spammer starts a campaing forging sender addresses to look like ours. All the backscatter that is not absolutely necessary is evil. I know, we are still sending it out, too, but I'm actively working on the issue.

-- Eino Tuominen

On Mar 25, 2008, at 2:51 PM, Eino Tuominen wrote:

The times, they are a-changing... We are facing a new world and old habits are not the best ways to do things anymore. I'm certainly
not one of those deeming all DSN's as evil, but it really hurts our users when some spammer starts a campaing forging sender addresses to look like ours. All the backscatter that is not absolutely necessary is evil.

Not all bounces are backscatter. My servers all deliver DSNs to the
sender. My servers don't send backscatter.

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source
and other randomness

Jo Rhett wrote:

...

Not all bounces are backscatter. My servers all deliver DSNs to the sender. My servers don't send backscatter.

On Tue, March 25, 2008 6:59 pm, Mark Sapiro wrote:

So now we're back to my original question. Under what circumstances is it acceptable for an MTA to accept a message and then later return an undeliverable DSN?

I thought previously you said 'none', but now you say your servers do it, so which is it?

My servers do it for mail accepted locally for relay, which is *only* SSL-encrypted and SMTP-AUTH mail. In short, zero chance of bouncing mail to a forged sender.

My server does not accept e-mail from random parties for relay. It either rejects it during the SMTP transaction, or delivers it.

-- Jo Rhett Network/Software Engineer Net Consonance

--On 26 March 2008 05:18:44 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

Eino Tuominen writes:

...

You are missing the point. Of course you can inform of a delivery problem, but only when you really need to do it. Every organisation should know of every recipient within their authority. You should know the recipient if you accept a message for delivery from outside your domain.

Says who? There is nothing in the standards that says so. And if you take that seriously, you have to disable .forward and procmail for individual users, as well as refuse to allow open subscription mailing lists and the like. This may make sense in the U.S. Army and in corporations with a military authority structure, but it does not in most universities, research, or open communities.

No, that's not true. I have about 10,000 users here. They have access to .forward files, but only a handful have worked out how to use them. Actually, we let them set auto-replies but only after the email has passed a very strict spamassassin threshold, and its rate limited, and its only for personal email (To and CC: recipents, no list headers, etc).

We do have open subscription mailing lists.

What we don't do is bounce emails with bad recipient addresses.

That is *not* the way Internet mail is designed to work. Mail, like every other application on the Internet, is intended to be decentralized. It is designed to allow load-sharing by use of intermediate and/or secondary MXes to handle primary crashes or overloads.

Yes, but they need to have equal access to user databases.

-- Ian Eiloart IT Services, University of Sussex x3148

--On 27 March 2008 08:56:54 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

Ian Eiloart writes:

...

No, that's not true. I have about 10,000 users here.

Interesting. I bet we're talking hundreds of thousands of users, just with the three or four of you medium-to-large-site admins that have posted so far. At a penny per user, I'm sure you could find somebody to do this work. I know I would do it (but you surely could find somebody cheaper and better-qualified ;-).

At a penny per user, I could raise £100. That wouldn't do the job. Unfortunately, UK academic institutions are cash strapped. We (Sussex) have contributed to UoW and Cyrus IMAP servers code, and to some other projects. Cambridge (somewhat less cash strapped) contributed almost all of the Exim MTA.

...

...

decentralized. It is designed to allow load-sharing by use of intermediate and/or secondary MXes to handle primary crashes or overloads.

Yes, but they need to have equal access to user databases.

I ask, where are these requirements written?

You mean the requirement that the mail system be able to reject email from non-members at SMTP time?

<http://wiki.list.org/display/DEV/Mailman+3.0> under "spam defenses". Third paragraph. It was there on July 21 last year, when the page was created from the Mailman 2.2 wish list.

I've been reading the Mailman lists for years. I know that you guys want the autoresponders configurable. However, often enough they've been presented as YAGNI,

Er. I guess that depends on what you mean by "need". Clearly nobody has died because we haven't got this feature. However, very many people have been inconvenienced. It's possible that Mailman bounces contributed to our site being blacklisted by AOL and Yahoo for short periods. It's certain that I've had to spend time helping list managers understand how to choose between the inadequate choices that they have for bad lists.

not a bug, and this is the first time I've heard a demand that they be shut off by default. Obviously you guys hang out together in some Big Site Cabal,

No... I spend more time on the Exim mailing list, but all the conversations that I've ever had about Mailman are on this list.

If you read the thread carefully, you'll find that my position is that this feature is a requirement, but not for 2.1, and maybe not even for 2.2. I just want it to happen eventually.

but what is common knowledge to you is not necessarily something that volunteer part-time developers are going to have easy access to.

That's why I post to the list.

BTW, that's not how I understand a secondary as a practical matter. Effectively, that is a distributed primary.

Yes. When I said the architecture is broken I meant the entire concept of the secondary. It's best to have a distributed primary, and not hard to implement with LDAP. Failing that, you have to choose between relying on third parties to queue your mail for later delivery or on queuing tons of spam on your secondary. I'd prefer to simply not have a secondary if it can't be of equal quality to the primary.

(I bet your "secondary" MXes deliver directly to user mailboxes, which are a shared resource like the user database. No?) Among other things, for most small- scale operations, the user database lives on the same host as the primary's MTA. If it is down, then under that requirement so are any secondaries.

-- Ian Eiloart IT Services, University of Sussex x3148

Stephen J. Turnbull wrote:

Ian Eiloart writes:

...

...

I ask, where are these requirements written?

You mean the requirement that the mail system be able to reject email from non-members at SMTP time?

I mean the document that says that backscatter is a mortal sin, not the document that says various people hold the personal opinion that it would be nice if Mailman would to stop all backscatter.

There is no such document. However you know that it's a mortal sin when you end up on several blacklists (and rightly so!) for having sent backscatter to innocent bystanders.

Not all questions of morality have to be formed into laws (nor can they).

--On Saturday, March 29, 2008 8:58 AM +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

...

However you know that it's a mortal sin when you end up on several blacklists (and rightly so!) for having sent backscatter to innocent bystanders.

Oh, brother! Look up "vigilante", and meditate on the definition until you realize that those are the words of a vigilante.

Is Wikipedia's definition acceptable?

A vigilante is a person who ignores due process of law and enacts his own form of justice when they deem the response of the authorities to be insufficient.

I see nothing wrong with that. Where I live, self-defense is acceptable.

Note that black lists don't block anything. They just report. It's like a web page that lists some group that the author thinks meets some criteria.

Others can then use the black lists they trust to block unwanted traffic. I hardly consider either action to be unreasonable.

[...] blacklisting some poor Ubuntu user, who just installs Mailman and creates a few lists because it says on the homepage that it tries to conform to the RFCs on mailing lists and provides some antispam features, and expects that it will therefore DTRT. [...] may be necessary, there's no way it's right.

Is it wrong for me to choose to not accept his traffic? Does the hypothetical "poor Ubuntu user" have a right to set policy on my server?

Mark Sapiro wrote:

Kenneth Porter wrote:

...

Note that black lists don't block anything. They just report. It's like a web page that lists some group that the author thinks meets some criteria.

Others can then use the black lists they trust to block unwanted traffic. I hardly consider either action to be unreasonable.

That's what the maintainers of black lists say, but in fact, the popular black lists are almost universally used by people who consider them a response to the spam problem without considering that the critera for being blacklisted and for being removed from blacklists are under control of the operators of the lists who guarantee no due process and are accountable to no one.

Who says that benevolent-dictator blacklists cannot be an effective response to the spam prolem?

And of course it is untrue that these benevolent dictators are accountable to no one. They are accountable to the users of their blacklists. If users learn that a blacklist is becoming too inaccurate, they will stop using it, or they would be shooting themselves in the foot by rejecting mail from innocent sources.

On Sat, 2008-03-29 at 01:18 +0000, Julian Mehnle wrote:

...

blacklists are under control of the operators of the lists who guarantee no due process and are accountable to no one.

Who says that benevolent-dictator blacklists cannot be an effective response to the spam prolem?

And of course it is untrue that these benevolent dictators are accountable to no one. They are accountable to the users of their blacklists.

Absolutely! I use a mix of 6 advisroy blacklists on my mail server. For my personal account, these stop about 80% of the spam sent to me, and probably a similar percentage for my customers and my mailing lists. I haven't had a complaint about a false positive from these blacklists in well over a year. The last time I got such a report was on an IP address blocked because it was listed by Spamcop - one of several false positives from this source. I dropped Spamcop from the mix and have had no such problems since then.

-- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | |

--On Saturday, March 29, 2008 3:51 PM +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

If you equate self-defense with justice, you are wrong. Vigilantes go beyond self-defense, and that's where they go wrong.

We're quibbling over definitions. It's impossible to find agreement under such circumstances.

No, but he's going to do it anyway. The policy you want (unless you've got something personal against him) is to never see spam and backscatter, and to receive the valid mails that pass through his server. You can't have that if you blacklist him. You can't have that if you don't.

FWIW, I use blacklists via SpamAssassin, invoked from a Sendmail milter, so it's not a black and white decision that relies on a single such list. A degree of consensus is required.

It might be straightforward to cook up some SA rules that recognize mailman backscatter and drop it, at the risk of dropping legitimate bounce notices.

Julian Mehnle writes:

You expect me to provide URLs showing what?

Actually, I consider you rather unlikely to provide any URLs at all.

You seem to be missing that the e-mail system is essentially an anarchy.

No, I just don't apply judgmental terms like "rightfully blacklisted" and "antisocial behavior" to what is at worst incompetence. In fact, I object to them, in large part because they are so often associated with turning a blind eye to the collateral damage done by many anti- spam measures, in particular blacklists.

Ian Eiloart wrote:

I think the reason that backscatter isn't subject to any RFC is that the real problem is the lack of authentication and accountability for return-paths in the original messages. Bouncing would be fine if you know that the email really came from the owner of the return-path.

That's what SPF and DKIM are intended to help with. There's friction in their adoption because certain features of email (notably mail forwarding, but also some others) have no regard for these features.

So far, so good.

Until no email service provider accepts message submissions outside of their own domains, all email providers offer message submission on port 587, all message submissions are autheticated, and mail forwarders accept responsibility for the email that they forward, it's not safe to bounce email.

This, however, is simply untrue. Of course what you said is desirable, but SPF can help with safely bouncing e-mail _today_. SPF may sometimes give an unexpected "Fail" result due to alias-style forwarding or other problematic cases, but when it gives a "Pass" result, it is always safe, i.e., the return path can be assumed to be authentic and bounces may be sent.

Ian Eiloart writes:

I think the reason that backscatter isn't subject to any RFC is that the real problem is the lack of authentication and accountability for return-paths in the original messages. Bouncing would be fine if you know that the email really came from the owner of the return-path.

That's what SPF and DKIM are intended to help with.

Aha, good point. OK, then the draft standards/RFCs for those qualify as far as I'm concerned. Note, I didn't mean that there must be an RFC saying "no backscatter", although you could read my words that way (and I certainly do demand it before I will consider this a purely technical problem). That would make things easy, of course, but those drafts/RFCs will most likely contain rationale for why we would like to outright ban backscatter, but can't quite go so far yet.

There's friction in their adoption because certain features of email (notably mail forwarding, but also some others) have no regard for these features.

By which you mean that SPF and DKIM in some configurations are as big a threat to Mailman as blacklisting for backscatter is, right?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mar 31, 2008, at 6:15 AM, Ian Eiloart wrote:

As far as DKIM is concerned, I think Mailman already can re-sign
messages. I don't remember the details, though. Anyway, I think re-signing is
the correct thing for a list to do. Again, Mailman is a winner here
because it's capable of doing such things.

IIRC, I think we decided that it was best to leave re-signing up to
the local MTA that Mailman delivers to, and not have Mailman itself do
the signing. Or am I misremembering that?

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA3SoACgkQ2YZpQepbvXGPtQCdE6ylXidmle/UkWVDjTWhp8Io 7nUAnjyVrFmWHSPUo0xDxaPINDZfgujS =xCar -----END PGP SIGNATURE-----

--On 12 April 2008 12:02:45 -0400 Barry Warsaw <barry@list.org> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mar 31, 2008, at 6:15 AM, Ian Eiloart wrote:

...

As far as DKIM is concerned, I think Mailman already can re-sign messages. I don't remember the details, though. Anyway, I think re-signing is the correct thing for a list to do. Again, Mailman is a winner here because it's capable of doing such things.

IIRC, I think we decided that it was best to leave re-signing up to the local MTA that Mailman delivers to, and not have Mailman itself do the signing. Or am I misremembering that?

I think you're right.

-- Ian Eiloart IT Services, University of Sussex x3148

Jo Rhett wrote:

On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote:

...

I still don't get what you mean by "properly deal with DSNs". Are you saying that an MTA should never return a DSN? It should either reject the mail during the incoming SMTP transaction or forever hold its piece?

Yes. And not just me, but a dozen different blacklists. RTFM "backscatter"

You can however safely send a DSN if an SPF[1] check for the incoming message passes.

1. http://www.openspf.org

Jo Rhett wrote:

On Tue, March 25, 2008 2:33 am, Julian Mehnle wrote:

...

You can however safely send a DSN if an SPF[1] check for the incoming message passes.

That's not "safe" but perhaps "safer". But a lot of sites can't use SPF so they either don't use it, or use soft-fail. I would only trust SPF results from explicit matches and PASS.

There are two parts to SPF: publishing SPF records for one's domains, and checking SPF on incoming messages. Everyone can do the SPF checking part, even if they cannot publish SPF records themselves for whatever reason. SPF's alias-style forwarding issues aside, "Pass" results, when achieved, are perfectly reliable and accurately indicate that the envelope sender address can safely be bounced to.

Jo Rhett wrote:

But for various reasons many organizations publish wide-open SPF records, and right or wrong those people will still report backscatter to the blacklists.

This is the first time I hear of this being a widespread problem. Can you please contact me off-list and give me some details on which organiza- tions do that? Perhaps the SPF project has to take them aside and have a friendly word or two with them.

In any case, this can be considered an abuse of the blacklists being reported to. For example, the SpamCop blacklist explicitly asks spam submitters to publish SPF records if they receive backscatter, so it is obvious that they aren't supposed to submit bounces as spam that are "legitimate" according to a published SPF record of theirs.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mar 24, 2008, at 10:03 PM, Jo Rhett wrote:

On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote:

...

I still don't get what you mean by "properly deal with DSNs". Are you saying that an MTA should never return a DSN? It should either reject the mail during the incoming SMTP transaction or forever hold its piece?

Yes. And not just me, but a dozen different blacklists. RTFM "backscatter"

I think you will be happier with what is possible in Mailman 3. In
mm3 we have a working LMTP server, those it's based on asyncore and
its scalability is questionable. Although I have not yet done this, I
plan to tie the rule chain checker into LMTP so that if your MTA
supports LMTP delivery the following can happen:

worldwildwonderland -> SMTP -> MM's LMTP -> rule checks

The rule checks then could tell LTMP to reject the message right
there, which would return 5xx to SMTP and /it/ would return 5xx to
whatever upstream SMTP its talking to.

Now, I wouldn't want to do a lot of work at that point, but some
simple checks would definitely be possible. You can reject messages
as early in the process as possible and do it at the SMTP layer.

While I think the LMTP code could be backported to 2.2, the rule
chains stuff cannot.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR+l6rXEjvBPtnXfVAQJMEQP/RVWLJNRtQbH3UsWCLLi76ef/fOhCP5h8 /k0V/dkM7gmM2efjnfoK30VR88gxcDAHXCFZ4DxYSFCcPleHRfcp/DTgrnBq3ezv 4eG76PIjXXNfXx+DVHiafORSBWavyYmtIvOjt75tT6VPO99GbO3dA6wwdtWkDDeD oWVR6pkzjSA= =oBVb -----END PGP SIGNATURE-----

I think you will be happier with what is possible in Mailman 3. In mm3 we have a working LMTP server, those it's based on asyncore and its scalability is questionable. Although I have not yet done this, I plan to tie the rule chain checker into LMTP so that if your MTA supports LMTP delivery the following can happen:

worldwildwonderland -> SMTP -> MM's LMTP -> rule checks

The rule checks then could tell LTMP to reject the message right there, which would return 5xx to SMTP and /it/ would return 5xx to whatever upstream SMTP its talking to.

Now, I wouldn't want to do a lot of work at that point, but some simple checks would definitely be possible. You can reject messages as early in the process as possible and do it at the SMTP layer.

It needs to be done after RCPT TO. LMTP allows you to sensibly do this later, and get return codes for individual recipients. However, it we're doing this with call forwards from an MTA which is receiving email over SMTP, then the MTA will have to check the sender/recipient pair at RCPT TO time.

on connect: accept the connection HELO/EHLO: reject if the sending MTA isn't known MAIL FROM: accept (perhaps unless the sender address is forbidden to post to all lists). RCPT TO: accept if the sender has permissions to post to the list, otherwise reject. This is the last chance to give a list specific response to an MTA that is engaged in a callout. DATA: reject null senders here if appropriate. Rejecting a null sender at RCPT TO or earlier might break callouts. ............. . Check the data, reject if inappropriate for a specific list (but this is likely to cause a bounce from our MTA). Because we've decided to trust the sender, we should be OK to bounce a message here, unless the list is an open list.

While I think the LMTP code could be backported to 2.2, the rule chains stuff cannot.

-- Ian Eiloart IT Services, University of Sussex x3148

--On 24 March 2008 18:45:22 -0700 Mark Sapiro <mark@msapiro.net> wrote:

Jo Rhett wrote:

...

If you have an MX that queues mail for someone else and isn't configured to properly deal with DSNs, then yes, you are stuck in the 20th century.

I still don't get what you mean by "properly deal with DSNs". Are you saying that an MTA should never return a DSN? It should either reject the mail during the incoming SMTP transaction or forever hold its piece?

Er, "peace". But yes. That should be the way that email sysadmins are thinking these days. But, it's a "should" not a "must", in the sense of RFC 2821 section 2.3 <http://www.apps.ietf.org/rfc/rfc2821.html#sec-2.3>

That's what it seems to me that you are saying. If that's not what you are saying, then perhaps you can explain under what circumstances a DSN is OK.

There are examples:

(1) Internal DSNs are OK if you don't accept inbound, unauthenticated mail from your own domain. (Actually, it's your domain so feel free to do what you like internally).

For example, we don't accept mail from our own domain unless it's authenticated, or carries a header saying that it's been through our server. Therefore we don't get spam with local SMTP return-paths.

So, my mail server can safely bounce email into my domain. In fact, if I'm handling an authenticated message submission, I prefer to bounce than to reject: some MUAs don't handle rejection properly.

(2) It should also be acceptable to bounce a message that gets an SPF pass (perhaps not from a +all entry, though), or if it carries a valid DKIM signature.

(2a) Given that SPF is available, this could be extended to domains that don't publish SPF records (yes, including us). If they don't care who's using their email addresses, then perhaps we should punish them by drowning them in backscatter!

(3) It's probably OK to bounce a message to a list member - perhaps if the message broke some list policy on message content.

-- Ian Eiloart IT Services, University of Sussex x3148

Cristóbal Palmer writes:

Even without the original message text a response is a problem.

I agree -- the addresses are too easy to compute and do end up in lists that are sold -- and would support consideration of changing the defaults as proposed.

But not for 2.1.10. Changing 2.1.10 is dumb software engineering and hysterical policy.

You see, as Jo Rhett points out (apparently without understanding), it will have *no noticable effect* in the short run because *the proposed change won't affect existing Mailman installations*, not even those that upgrade to 2.1.10.

So the right thing to do is to get 2.1.10 out the door as is, and get started on 2.2. Then you can even discuss shutting off the feature in *existing* installations and requiring admins of *existing* installations to reactivate the feature if they want it.[1] That would very likely have noticeable effect *much sooner* than the change proposed for 2.1.10, and would be much less disruptive.

Footnotes: [1] Indeed, I think that makes sense, but I have no intention of participating in discussion until after release of 21.1.10.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mar 5, 2008, at 12:27 AM, Stephen J. Turnbull wrote:

Cristóbal Palmer writes:

...

Even without the original message text a response is a problem.

I agree -- the addresses are too easy to compute and do end up in lists that are sold -- and would support consideration of changing the defaults as proposed.

But not for 2.1.10. Changing 2.1.10 is dumb software engineering and hysterical policy.

You see, as Jo Rhett points out (apparently without understanding), it will have *no noticable effect* in the short run because *the proposed change won't affect existing Mailman installations*, not even those that upgrade to 2.1.10.

So the right thing to do is to get 2.1.10 out the door as is, and get started on 2.2. Then you can even discuss shutting off the feature in *existing* installations and requiring admins of *existing* installations to reactivate the feature if they want it.[1] That would very likely have noticeable effect *much sooner* than the change proposed for 2.1.10, and would be much less disruptive.

Mark's the release manager for 2.1, but FWIW I completely agree with
Stephen about this. What I would suggest though is that this
information be put in a prominent place on the wiki. We have a
security space with nothing substantial in it, so I suggest we put it
here.

http://wiki.list.org/display/SEC/Home

This will get much more publicity and community input than in a README
file. This is something you can do right now <wink>.

We need to get 2.1.10 out and move on. I hope Jo, Cristobal, Ian and
others will help us solve these problems in MM2.2 and 3.0.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkfPJKcACgkQ2YZpQepbvXGicQCeMN5dv4sutxfUfzvL1FHNzZp1 McAAoIGPH+NOxU+nzOrlzV4egzw8EYtg =d5ci -----END PGP SIGNATURE-----

Kenneth Porter wrote:

On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw <barry@list.org> wrote:

...

[...] We have a security space with nothing substantial in it, so I suggest we put it here.

http://wiki.list.org/display/SEC/Home

This appears to be a read-only space. The add page link on the dashboard is grey and there's no Edit tab on the main page.

Did you 'Sign Up' and/or 'Log In'?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Kenneth Porter wrote:

Yep, I created a login and see the Log Out link at top. The COM, DEV, and DOC sections are editable. SEC is not.

I expected that the other 3 spaces are only editable when one has a login and thought perhaps SEC had been created with some kind of special group requirement, to keep crackers from seeing exploitable issues before a fix was available.

You are correct. My bad. since I am a member of a special group (not special enough to change Space Permissions though), I created a non-special user to see if it could add/edit pages. Foolishly, I then just went to a few pages to see if I had an edit tab, but I didn't actually go to the SEC page.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

--On Thursday, March 06, 2008 9:03 PM -0500 Barry Warsaw <barry@list.org> wrote:

Try it now. At one point I thought the entire space should be write restricted to just the core developers, but I think that's misguided. I've opened up the permissions and we can lock specific pages if/when we find that necessary.

I can edit it now.

Using Mozilla Seamonkey, the Rich Text tab shows a tiny edit window with what looks like HTML to edit. The Wiki Markup tab gives me a Page Not Found. Does Confluence work well with Firefox? Seamonkey should behave nearly identically but some browser detectors get confused by it.

--On Friday, March 07, 2008 9:16 AM -0500 Barry Warsaw <barry@list.org> wrote:

I haven't tried Seamonkey, but just be sure you have JavaScript enabled. You probably already do, but I think that'll make a difference.

Aha! That was it. I'd allowed it on FF yesterday at the office, but not this morning on Seamonkey from home. (I've got the NoScript addon going.)

On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw <barry@list.org> wrote:

Mark's the release manager for 2.1, but FWIW I completely agree with Stephen about this. What I would suggest though is that this information be put in a prominent place on the wiki. We have a security space with nothing substantial in it, so I suggest we put it here.

Initial text here:

<http://wiki.list.org/display/SEC/Controlling+spam>

I grabbed some text from Jo Rhett's initial post in this thread and then added what I did to my installation. Those with more of a "big picture" view of the system can refine this.

--On Friday, March 07, 2008 4:31 PM -0800 Mark Sapiro <mark@msapiro.net> wrote:

I changed the last part. Take a look. Note that sitelist.cfg is irrelevant. It is intended to be used as input to bin/config_list to configure the site list ('mailman' list) more appropriately than the default settings. It has no actual effect on any list unless you run bin/config_list on that list with sitelist.cfg as input.

The new text says to change generic_nonmember_action but not where to change it. I see it in /var/lib/mailman/data/sitelist.cfg which I believe is site-wide and probably suffers the same issue. I haven't yet found it in the web interface. (It might be nice if the web interface included an "all settings" page, or at least an index of settings so one could then go to the specific page with that setting.)

Ideally I should be able to change it in a text file or otherwise with a shell utility, so that I can bulk-change the setting in all lists I manage with a script.

--On Monday, March 10, 2008 10:02 PM -0700 Mark Sapiro <mark@msapiro.net> wrote:

Maybe you can come up with some good text to add to the wiki page.

Thanks for the details. Wiki updated.

Kenneth Porter wrote:

--On Friday, March 07, 2008 4:31 PM -0800 Mark Sapiro <mark@msapiro.net> wrote:

...

Also, if you're happy with the way the new mm_handler is working, let me know, and I'll get it in the contrib directory for 2.1.10.

I'm seeing lines like the following in maillog. How do I trace the source of the error? (I can debug code in an Emacs/shell situation, I just don't know how to debug within the sendmail/mm-handler/mailman environment to isolate the offending module and line.)

Mar 10 11:13:30 centos sendmail[26008]: m2749udR026109: to=<tvservers@lists.matureasskickers.net>, delay=3+14:03:32, xdelay=00:00:00, mailer=mailman, pri=7863419, relay=lists.matureasskickers.net, dsn=4.0.0, stat=Operating system error

In sendmail.mc:

Mmailman, P=/usr/local/sbin/mm-handler, F=rDFMhlqSu, U=mailman:mailman, S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u

My only change to your script was the Perl location in the shebang and these two lines (to match the CentOS RPM file locations):

$MMWRAPPER = "/usr/lib/mailman/mail/mailman"; $MMLISTDIR = "/var/lib/mailman/lists";

I am not the author of mm-handler - that's David Champion. I'm just the release manager for the 2.1.10 release. I'm not well versed in either perl or sendmail, but I'm surprised sendmail doesn't log more.

In any case, my guess would be a permissions issue or a group mismatch from the mailman wrapper, but if everything is the same as with the previous mm-handler, then that should not be the case.

You could try running mm-handler by hand. I think it would be something like

/usr/local/sbin/mm-handler your.host.name listname < file_with_raw_msg

You might want to uncomment the $DEBUG = 1; line when you do this. If I read your sendmail.mc fragment correctly, you want to do this as user:group mailman:mailman.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

BTW, the experimental mm-handler isn't currently letting posts through, but I haven't had a chance to debug it. I'll try to look at it this weekend. It no longer reports an error, though, once I fixed the permissions.

On Mar 4, 2008, at 9:27 PM, Stephen J. Turnbull wrote:

You see, as Jo Rhett points out (apparently without understanding), it will have *no noticable effect* in the short run because *the proposed change won't affect existing Mailman installations*, not even those that upgrade to 2.1.10.

I understood. I'm trying to stem the flood of new installations that
have this feature.

So the right thing to do is to get 2.1.10 out the door as is, and get started on 2.2.

No, it isn't. Based on current pace you're pushing the problem out
for 2+ years.

Then you can even discuss shutting off the feature in *existing* installations and requiring admins of *existing* installations to reactivate the feature if they want it.[1] That would very likely have noticeable effect *much sooner* than the change proposed for 2.1.10, and would be much less disruptive.

Huh? How exactly are you going to shut off the feature in an
existing installation?

Sorry, as stated your proposal sounds either naive or insane. No
insult intended.

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source
and other randomness

On Mar 24, 2008, at 11:21 PM, Stephen J. Turnbull wrote:

Pure bluster. You have no data about "floods of new installations",

We turn up X customers a week. We see X customers a week running
into problems and getting blacklisted for backscatter. This is the
"flood" I am trying to solve.

What is your problem? I'm solving a technical issue. This kind of
personal attack is irrelevant, and pointless. I don't care.

...

...

Huh? How exactly are you going to shut off the feature in an existing installation?

1. By fiat from the ISP, eg as you threaten to change your AUP. This would be most likely to well-received by ISP clients if combined with:

It's not a change of AUP. Mailman currently violates the AUP.

And yes, we can force them to fix their installations with good
documentation. We have it, but people protest that you don't support
it. That was why I said two things were necessary - a documentation
fix and a defaults fix. Read my original posts.

implied changes to the code, of course) would shut off the autoreplies for *every* existing Mailman installation that upgrades. This will not be feasible with your proposed change to 2.1.10.

I don't care what changes are made. Don't waste time on my proposal,
do something better.

...

Sorry, as stated your proposal sounds either naive or insane.

No, just radical and unlikely to be implemented. But if implemented it will do one heck of a lot more for the backscatter problem than panicking as you propose we do.

Hyperbole like this wastes everyone's time.

I don't care what is done. Do something that makes it better.

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source
and other randomness

Jo Rhett wrote:

...

I don't care what is done. Do something that makes it better.

On Tue, March 25, 2008 9:12 pm, Dale Newfield wrote:

This is an open source project. You are welcome to use it as is or modify it to your liking. (I believe--someone confirm, please) you even have the right to distribute your modified version. You're welcome to make whatever changes you'd like for your own use or even offer the patches to this OPEN SOURCE project. Seeing as those running this are volunteers I see no reason they should jump to do your bidding. Seeing your attitude I see no reason they should want to.

You're missing the point. I'm an Abuse Admin. This isn't my problem, nor is it my bidding. If you run Mailman, this is *YOUR* problem.

I can, and frankly SHOULD HAVE, banned Mailman from the networks I'm responsible for. I'm here to try and get a more reasonable resolution.

And when people like you insult and attack me, all you do is contribute to the ongoing perception that mailman developers don't care about the backscatter problem, which is why a lot of us abuse admins are preparing to disallow Mailman on our networks.

Now take your attitude problem and put it somewhere useful.

-- Jo Rhett Network/Software Engineer Net Consonance

Joshua 'jag' Ginsberg wrote:

For what it's worth, you've stated your problem with impeccable clarity. What you haven't done with the same aplomb is acknowledge and respond to the equally legitimate concerns of the developer community here.

I have tried to. I've even wasted time responding to people who don't seem to understand the issues involved at all.

• • "I am asking that the developers start paying attention *NOW*."
• -- Reply: "Nobody has said they should ignore the problem, just that *you* are *way* too late in the process to expect them to stop the release of 2.1.10 for this major change in behavior."

Invalid in that this issue has been known since long before 2.1.10 or honestly even 2.1.6 was thought of. It's the same excuse with every release.

• • "This is not substantive, it's trivial."
• -- Reply: "From the point of view of the release manager, there are no trivial code changes to a release candidate."
• -- Reply: "A text change breaks 35 existing Mailman translations, and

This I did acknowledge. Check the mail archive.

And you're intermixing it with impatience and superciliousness:

If you look, I only responded in that manner to people who insulted or attacked me first. *And* in most cases I responded thoughtfully and dry to apparent insults to first, second... sometimes third time. But I'm human.

A better question is why are people with zero apparent experience on this matter responding to me with insults and attacks? My posts were entirely technical, and their inexperierence is apparent. Their inability to work on the code base themselves is also apparent. All this does is make me regret attempting to intervene in this matter in the first place.

Like it or not, Mailman is a major development project with limited volunteer resources. It has strategically determined its own course -- security fixes and translation updates only for 2.1; new features without major redesign for 2.2; major redesign for 3.0 -- and it has a standard professional release cycle. ... And you need to respect that to keep a stable, reliable product with the limited volunteer resources it has, Mailman must follow these development guidelines.

No I don't. My job is to enforce our AUP. My job is not to come onto mailing lists with perfectly valid issues that are so very well known they are reported in the non-technical news media, and get abused for bringing them up.

A compromise for 2.1 has been proposed -- a README.backscatter file, better wiki documentation, and getting the information out so that under the 2.1 framework backscatter can be minimized through sysadmin awareness. I encourage you to take the lead in this effort since the issue is clearly important to you.

No, this issue isn't "important to me". Doing my job is important to me. Preventing the next backscatter DoS against our mailservers (which was 60% mailman traffic) is important to me.

Since everyone already thinks that I'm a jerk, let's go all the way. Shutting down Mailman permanently, throughout the 'Net, *SHOULD* be important to me. It's the best possible fix for the problem at hand. Why I chose to try and work with the developers to get a fix into place is a curious thing, because it certainly won't solve the problem today and it's clearly been a waste of time.

Mailman is a community project, and you'll find a receptive and helpful audience for your issue when you give the community's concerns the consideration they deserve.

I think you need to go back and look at my original posts, and the abuse and derision and insults I received. The problem is not that I failed to give the community's concerns respect. You'll find, if you look honestly, that the problem went entirely the other way. There wasn't a single response within a week of my original post that had anything verging on respect for the very well known issue in it.

Anyway, I'm done.

-- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mar 26, 2008, at 3:02 PM, Jo Rhett wrote:

You're missing the point. I'm an Abuse Admin. This isn't my
problem, nor is it my bidding. If you run Mailman, this is *YOUR* problem.

Ah, Abuse is down the hall. This is Getting Hit On The Head lessons
in here.

pythonic-ly y'rs,

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA5L4ACgkQ2YZpQepbvXESlgCghHqwW53Z528Efn2Yo7eA5rTd H4EAnjRv/c+wtVkYc8wvAvQh7dmA827w =7cMR -----END PGP SIGNATURE-----

Jo Rhett writes:

What is your problem?

But that's the whole point. I don't have a problem, although you have made me aware that I may have one in the future. Still, it's not pressing. So I want 2.1.10 released ASAP, which means as is, and I can wait for 2.1.11. I also honestly believe that's the best policy for Mailman.

I don't care what is done. Do something that makes it better.

I'm not in a position to volunteer. It doesn't really sound like anyone else is, either. Have you thought about providing compensation to get this done?

Jo Rhett writes:

I'm here out of good will,

I believe you, but your posting style provides zero evidence for it.

trying to avoid the banning of Mailman from dozens of large ISPs. This kind of response just makes me think I'm wasting my time.

Well, yes, that's what we've been saying. The resources to do what you say is necessary are not currently available. As you've remarked yourself, 2.2 is dead in the water and 3.0 is a long time away. 2.1 gets a new release every so often with a few bug fixes, and this is only really possible because it's in pure maintenance mode -- feature changes are mostly rejected out of hand. Those aren't symptoms of a project flush with resources.

The technical problem of backscatter has been acknowledged. From the posts to this thread, I conclude the Mailman community *at large* is at present unaware of the threat of banning. I gather that includes Mark but perhaps not Barry. On the other side, there are very few resources available, and for this kind of change there is special pressure on the translators; no one of us can do it alone.

The question is where to get the resources. While it's not your responsibility to do it, it isn't anybody else's, either.

Regards,

--On 24 March 2008 18:07:29 -0700 Jo Rhett <jrhett@netconsonance.com>

...

Sorry, as stated your proposal sounds either naive or insane. No insult intended.

On Wed, March 26, 2008 3:07 am, Ian Eiloart wrote:

Please, think harder about what you write to the list. If you left an insult in there that you were aware of, then you *are* intentionally insulting people.

No, I wasn't. But in case someone misread my statement regarding patent facts of already installed software as an insult, I added the disclaimer to make it clear. My remarks were entirely fuctional. Short of writing a worm, you can't fix existing installations after the fact.

I'm on your side in theory. I've been asking various mailing list developers to address this problem for years, with no progress anywhere. But, I've lost patience with your apparent aggression here.

Why is your patience satiated with Mailman, but lost with me? I think you need to turn those guns around and point them where they belong.

I have no aggression. I do have a general desire to see this problem solved, and I'm frustrated by the complete lack of action.

I sat through a meeting where every single abuse admin says that they can't get Mailman installations to deal with the problems involved, even when full documentation for how to solve the problem is provided - because Mailman doesn't support the changes. And general agreement that it was perhaps time to close the door.

So I'm here, wasting my time, trying to get this solved so that just maybe we won't be forced to all migrate to web forums. Which would suck.

-- Jo Rhett Network/Software Engineer Net Consonance

Cristóbal Palmer wrote:

So far I see documentation and some good scripts for fixing problems on existing systems coming out of this conversation.

As per my original statement, that would be great.

Please let's make improving that documentation and making 2.2 and 3.0 good by your standards a priority.

None of these are "my standards". The standards expoused by the leading anti-spam groups are what we are talking about.

Jo, would you please be willing to take the lead in improving this wiki page:

...

http://wiki.list.org/display/SEC/Controlling+spam

since it looks rather stubbish? If you're willing to lead by example on the documentation and 2.2, your argument would likely come off a bit better.

I've written some points about what is not covered in that to the list. The problem is that what I did on the mailman install I was responsible for was fairly hackish. I can program in almost anything, but Python is not my strong point and the Python.org style used in Mailman even less so. This makes my patches fairly hackish and probably not the best way to do things. (more on this below)

Now, if your goal is a public telling-off of the mailman team, I think you've already made that clear enough. Can we move on?

Never did, never was. Have repeatedly asked that we move on ;-)

This open source world is a group effort that runs largely on good will and sharing. Your currency here often isn't valid if it doesn't come with a smile.

For projects where I am asking something of them, my approach generally comes with a smile and a patch. In fact, if you look at the sourceforge patch repository you'll find that my functionality requests *did* come with patches.

This situation is different, because the request is going the other way. Mailman sites have been asking abuse departments to ignore the backscatter and smile for far too many years. The smiles have long since faded and most of us are frustrated with the situation. I took on role of trying to push the developers to put something in place before we simply banned mailman within our networks.

There is nothing personal here. It is entirely technical, and entirely goal oriented. The difficult part is that none of us at that meeting or in any of the conversations I'd had with others since then are strong Python developers.

And in fact, if you look back at my submitted patches and comments on this list -- I have in all cases asked what changes would make the patch workable and acceptable for inclusion into the codebase, and received no responses to that. So we have fairly apparent opinion that my patches aren't stylistically worth considering. I'm not surprised, given that I don't personally grok the Python.org style. I'm not offended, just aware that my patches are unlikely to be useful in this effort.

-- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness

--On 28 March 2008 17:27:05 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

Jo Rhett writes:

...

The standards expoused by the leading anti-spam groups are what we are talking about.

URLs to (some of) these standards, s'il vous plait. RFCs (including BCPs) or Internet-drafts preferred, of course, but web pages of similar quality, intended as BCPs, would do. No Wikipedia, please; Wikipedia does not pretend to publish standards.

Here's a page on the Exim wiki: How To Do Autoreplies Without The World Hating You <http://wiki.exim.org/EximAutoReply>

UK Joint Academic Network provides network connectivity and services for UK HE institutions, here's their guidance to victims of backscatter: <http://www.ja.net/services/csirt/advice/policies/collateral-spam.html>

A talk given at a UK Unix User Group meeting. Look for the 5th abstract on this page: <http://www.ukuug.org/events/winter2005/programme.shtml>

<http://www.dontbouncespam.org/> <http://spamlinks.net/prevent-secure-backscatter.htm>

The inevitable "...considered harmful" article: <http://mayfirst.org/?q=node/180>

-- Ian Eiloart IT Services, University of Sussex x3148

--On 29 March 2008 13:31:47 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

Thank you, Ian!

Oh, one more link:

From JANET again: Spam Bounces Considered Harmful

<http://www.ja.net/services/csirt/threats/bounce.html>

Their advice is plain: "Reject, Don't Bounce The standards provide for a mail server to 'reject' a message by refusing its transfer, rather than accepting it and risking future problems."

-- Ian Eiloart IT Services, University of Sussex x3148

Mark Sapiro wrote, On 03/31/2008 06:26 PM:

So what do I do practically in this case. Calling out to verify the recipient won't help because the recipient is valid.

I think that we - admins and developers - have to realize that times are changing.

Once upon a time when the RFCs were written then mail was asynchronous store-and-forward. MTAs accepted mails before being 100% certain that they could and would deliver them, and as soon as the mail had hit the disk then the receiving MTA took over delivery responsibility from the sending MTA.

In such a scenario Mailman "is just" a MTA with bouncing/holding filtering and dynamic alias expansion of envelope-rcpt and replacement of envelope-from with a robot address.

But now in modern times all mail handling has to be synchronous. Spam and virus and backscatter does that a MTA should never take responsibility for anything from an untrusted sender before the mail has actually been taken fully care of by someone - perhaps just by making it the problem of the next MTA/MDA. Yes, doing this all the way to the final mailboxes might be more expensive than the old way of doing it - but at the same time the same amount of work (or less?) has to be done, so it can't be that bad ... except for the number of live connections. I think that the RFCs allows fully synchronous mail handling, they just have to be used another way than they usually are today.

In Marks specific case in this scenario: The verification phase has been replaced by actually doing the delivery all the way to the final recipients, so the recipient ending up being invalid will be handled properly.

In this scenario Mailman is a MTA which decouples the synchronous chain. Mails are accepted and enqueued by Mailman iff responsibility is taken, either for immediate delivery or manual review - all other mails are rejected. All filtering thus has to be done synchronously. Delivery to list members is a separate process where target mail hosts probably will provide synchronous delivery status feedback (perhaps as DSN bounces from a trusting "real" MTA) (and if other mail hosts chooses to accept and then bounce later then they have a problem, but Mailman can still handle receiving bounces).

Lots of details are missing in this description. But do you agree that this is the direction we have to take as developers and admins?

/Mads

ps: This might be a bad description of trivial observation, but it suddenly made sense to me and I wanted to share it, even though I'm mostly a lurker on this list. Take it or leave it ;-)

--On 31 March 2008 09:26:08 -0700 Mark Sapiro <mark@msapiro.net> wrote:

Ian Eiloart wrote:

...

[snip]

Here's the problem. I receive a message for board@example.net which is aliased to a few other addresses including user@example.com. The MTA (Postfix in my case) accepts the message to board and resends it to the aliased recipients. example.com has a very agressive content filter which rejects messages after receiving the DATA. so Postfix's delivery to user@example.com is sometimes not accepted by example.com so Postfix returns a DSN. Sometimes the sender was legitimate, sometimes (probably more often) not.

So what do I do practically in this case. Calling out to verify the recipient won't help because the recipient is valid.

So, these are mail aliases that aren't managed by Mailman? Well, you could turn them into Mailman lists - albeit lists of one. Mailman would alter the return-path, and the rejection message would go to a list manager - perhaps the domain owner - instead of an innocent third party.

Also, you could perhaps arrange that Postfix only bounces into domains that publish SPF records, and only when you get an positive SPF response. Actually, I'm veering towards the notion that we should be creating a climate where the only sensible way to avoid collateral spam is to publish SPF records.

I can arrange for the DSN to pass through MailScanner on the way out and possibly create rules to conditionally drop it, but what should the rules be, and is it really a problem at all? Note for example, that yesterday I did not accept 29985 messages for unknown users and greylisted 5684 more and sent no DSNs. This is somewhat typical except I probably average 2 or 3 DSNs per day.

Should I be worried?

That depends on the nature of your customers. But, you should also be concerned about the possibility of one day being flooded by DNS generating mail. At the current rate, it's a small problem [but a part of a larger problem], but what you have might be regarded as a vulnerability.

-- Ian Eiloart IT Services, University of Sussex x3148

--On 1 April 2008 13:15:42 -0400 Dale Newfield <Dale@Newfield.org> wrote:

Ian Eiloart wrote:

...

Actually, I'm veering towards the notion that we should be creating a climate where the only sensible way to avoid collateral spam is to publish SPF records.

That's not always trivial. I get plenty of back scatter, and I've tried to do this to reduce that, but I've been unable. My domain is for my family, so each person is in a different part of the country using numerous paths to send out mail (local ISP, gmail, web-mail through my server, a roaming SMTP service, various cell phones, blackberries, etc.), so I've not been able to come up with a complete list of what machines can send valid mail from my domain.

-Dale

The long and the short of it is this: as long as you permit email with return-paths in your domain to be injected into the mail system without authentication and authorisation, then you'll suffer backscatter, blacklisting, content scanning and all sorts of other problems.

Ultimately, you'll HAVE to find a way that your domain users can submit messages through a server (or virtual server) that YOU manage. Your family's ISPs might be able to authenticate their customers, but they probably can't know that your family members are authorised to use your email domain.

I had a similar problem with my private domain: eiloart.com

First, I rented a virtual server. That turned out to have a pretty cruddy qmail installation (which would lose mail if it ran out of RAM during delivery!), so I got the domain's email service provided by Google apps. <http://www.google.com/a/help/intl/en/index.html> It provides authenticated SMTP submission, including on port 587, POP and IMAP. Works nicely on my iPhone, with Apple Mail, etc. One issue: I don't seem to be able to use both my personal accounts at the same time on my iPhone, but it's OK with Apple Mail.

Sorry, this is only vaguely on topic. Mailman doesn't really suffer the message submission problem in a big way.

-- Ian Eiloart IT Services, University of Sussex x3148

On Saturday, April 12, 2008 12:44 PM -0400 Barry Warsaw <barry@list.org> wrote:

Thanks! Capture here in the "best practices" section:

http://wiki.list.org/display/DEV/Home

Note that there's already backscatter prevention info here:

<http://wiki.list.org/display/SEC/Controlling+spam>

One of these pages should be linking to the other. Or perhaps a new "backscatter resources" page should be created for both to point to.

On Wednesday, March 26, 2008 8:18 PM -0400 CristóbalPalmer <cmpalmer@metalab.unc.edu> wrote:

Jo, would you please be willing to take the lead in improving this wiki page:

http://wiki.list.org/display/SEC/Controlling+spam

since it looks rather stubbish?

Agreed. I grabbed text from Jo's original post to get it started, added some of my own supposition, and Mark Sapiro corrected my mistakes. I'd love to see others with experience take it out of stub-hood.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mar 4, 2008, at 8:13 PM, Cristóbal Palmer wrote:

On Tue, Mar 04, 2008 at 03:28:22PM -0800, Mark Sapiro wrote:

...

The Defaults.py setting for DEFAULT_GENERIC_NONMEMBER_ACTION has been Hold from the beginning.

We've recently set this to 3 (Discard) for new lists. Please explain the argument for keeping the default as Hold for the long term. I believe it should be Discard, but can think of at least one argument for keeping the current default. I'd like to hear development team's line.

More and more lists are requiring membership for posting privileges,
so I'm sympathetic to this change (but not for 2.1!). OTOH, I think
there are ways that we can do this but still relax the constraint for
well-known non-members.

For example, in MM3 the data model has been improved so that you have
a single user object that ties in all your subscriptions. No more
multiple passwords or options (unless you want the latter), no more
multiple accounts for each of your email addresses.

What if in the future, your site had 1400 lists, the membership
databases of which were driven from your site's membership rosters.
Now, someone you've never heard of before posts to one of your lists.
You probably discard this (although there /are/ arguments to be made
for some lists holding these messages instead).

But let's say that I join your site and register an email address.
Now I post to one of your lists which I haven't explicitly subscribed
to. But you know me so do you discard the message, hold it, or let it
through? Let's say you hold it, and a list admin approves it, saying
"hey this guy looks legit". Let's say you do this 5 times across 3
different lists. I'm probably not a spammer, right? So maybe now I
can post to all your lists without being held.

Anyway, it's things like this that I think can be used to help reduce
spamming on the list while letting legitimate traffic through, without
Mailman becoming spamassassin. OTOH, in MM3 it'll be much easier to
integrate something like spamassassin than it is in MM2. I'm not
saying that's a /good/ thing since spam still is better off getting
caught in the MTA, but this kind of thing is possible.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkfPJycACgkQ2YZpQepbvXHQ8ACgiMNs46R8OcItJtjoCAbIQHaO a2AAnif160xr7GhjOWWQ6Qvcxle7f70R =TyH6 -----END PGP SIGNATURE-----

On Thursday, March 06, 2008 4:02 PM -0600 David Champion <dgc@uchicago.edu> wrote:

Here is an update to mm-handler which might address this adequately. I no longer use mm-handler myself (despite having written it), so I can't test this short of installing a new Mailman instance. Can someone on the list test it?

http://home.uchicago.edu/~dgc/sw/mailman/mm-handler/mm-handler-2.10

Since it's contrib and not supported, maybe it would be reasonable to put the update into the 2.1.10 release -- provided someone can declare that it works. :) Otherwise feel free to post it on the wiki.

I'll give it a shot.

Question about the backscatter settings:

# Prevent backscatter for unapproved actions? $BounceUnapproved = 0;

# Prevent backscatter for undefined lists? $BounceNonlist = 1;

The comment seems to be logically backwards from the variable name. Should it really read "allow", not "prevent"? Does 0 or 1 mean backscatter?

--On Thursday, March 06, 2008 4:02 PM -0600 David Champion <dgc@uchicago.edu> wrote:

Here is an update to mm-handler which might address this adequately. I no longer use mm-handler myself (despite having written it), so I can't test this short of installing a new Mailman instance. Can someone on the list test it?

http://home.uchicago.edu/~dgc/sw/mailman/mm-handler/mm-handler-2.10

Since it's contrib and not supported, maybe it would be reasonable to put the update into the 2.1.10 release -- provided someone can declare that it works. :) Otherwise feel free to post it on the wiki.

I made some tweaks and discovered it won't work with a list with a dash in the name, due to the regex used to extract the action suffix. Can someone more nimble with regex let me know how to adjust it?

<http://matureasskickers.net/MISC/mm-handler.experimental>

I also changed the "printf STDERR" to syslog to my maillog.

Here's the before/after regex:

< if ($addr =~ /(.*)-(.*)\+.*$/) {

  if ($addr =~ /(.*)-([^-]+)\+.*$/) {

I should have read the error reply more closely. It gave me back this:

Your mail for tribes2-pickups@lists.matureasskickers.net could not be sent: no list named "tribes2-pickups-pickups" is known by lists.matureasskickers.net

That should be easy to chase down.

Since I patched the script to syslog I think I now have enough functionality that I can debug this printf-style.

--On Friday, March 28, 2008 4:29 PM -0700 Mark Sapiro <mark@msapiro.net> wrote:

In case you haven't got it already

Thanks, just found it myself. ;)

I'll put an updated copy on my website shortly. (Will also have fixed comments.)

<http://matureasskickers.net/MISC/mm-handler.experimental>

Sorry for the bugs and such, and thanks for working it out. I feel bad about posting and abandoning, but I actually have no infrastructure to test this anymore.

When I first contributed that script I only knew enough Python to debug Mailman, and was pretty comfortable with Perl. Now that I <3 Python and really can't stand Perl, I would like one day to redo the thing in Python. But I'm going to make it a little more "drivery", in that it'll handle Mailman or Sympa (our management's choice to replace Mailman) or anything else you plug in a ListManager subclass for. I'll probably try to use it for driving RT, for example.

I'll post again when I've had a chance to make progress.

-- -D. dgc@uchicago.edu NSIT University of Chicago

--On Friday, March 28, 2008 7:08 PM -0700 Mark Sapiro <mark@msapiro.net> wrote:

I would like to get this in the contrib directory for Mailman 2.1.10. I can do this in several ways. One would just be to replace the existing mm-handler and update the README.mm-handler as needed. That might be the cleanest.

A second approach would be to update the README.mm-handler to indicate there are two versions and include your version as either a separate file or as a link to your web site.

Do you (or does anyone else) have any thoughts on this?

I don't have any preference. My version does depend on the presence of the syslog module, and I don't know how commonly-installed that is. But I don't know under what systems the debugging to stderr is supposed to work. Is that a Sun thing?

Kenneth Porter wrote:

I don't have any preference. My version does depend on the presence of the syslog module, and I don't know how commonly-installed that is. But I don't know under what systems the debugging to stderr is supposed to work. Is that a Sun thing?

I just checked, and my CentOS 5 system only has Sys::Syslog and not Unix::Syslog. It might be worthwhile to provide your version plus a patch to go back to the old DEBUG w/o logging. OTOH, Unix::Syslog is available from CPAN, DAG, etc., so I don't think it's unreasonable to expect people to be able to get it.

As I understand it (possibly wrong), the way this

if ($DEBUG) {
	$to = join(',', @to);
	print STDERR "to: $to\n";
	print STDERR "sender: $sender\n";
	print STDERR "server: $server\n";
	exit(-1);
}

works is it exits with an error, so sendmail returns an undeliverable status/notice containing the script output.

Obviously, your logging is much nicer.

I have another question since I don't know sendmail. Does sendmail execute mm-handler at incoming SMTP time, and if so, does an error exit from mm-handler result in an SMTP failure status being returned to the sending MTA?

If so, it seems that rather than just dropping a 'bad' message as mm-handler seems to do when $BounceUnapproved = 0; and $BounceNonlist = 0;, wouldn't it be better to exit with a failure status.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

David Champion wrote:

Correct. But as previously noted, syslog might not log anything at all on some systems -- that's why mm-handler didn't use it originally. And this is debugging code, not meant for live environments....

True, but Kenneth added additional logging beyond the debuging code.

Also, There are two perl modules, Sys::Syslog and Unix::Syslog. I'm not very familiar with perl and it's various modules, so I may be wrong, but I think that Sys::Syslog is the more common, but Kenneth is using Unix::Syslog. According to the FAQ at <http://search.cpan.org/~mharnisch/Unix-Syslog-0.100/Syslog.pm>, Unix::Syslog requires syslogd to be running on the local host, but given that, it doesn't communicate with syslogd through a network connection so it is not subject to the problems with that.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

--On Saturday, March 29, 2008 9:37 AM -0700 Mark Sapiro <mark@msapiro.net> wrote:

I just checked, and my CentOS 5 system only has Sys::Syslog and not Unix::Syslog. It might be worthwhile to provide your version plus a patch to go back to the old DEBUG w/o logging. OTOH, Unix::Syslog is available from CPAN, DAG, etc., so I don't think it's unreasonable to expect people to be able to get it.

I've got perl-Unix-Syslog-1.0-1.el5.rf installed from RPMForge. There's a page in the CentOS wiki that explains how to enable this yum/RPM repository.

I have another question since I don't know sendmail. Does sendmail execute mm-handler at incoming SMTP time, and if so, does an error exit from mm-handler result in an SMTP failure status being returned to the sending MTA?

Correct. mm-handler is a "mailer" which is invoked upon receipt by sendmail, which typically happens via SMTP. (Sendmail can also accept mail via local socket, or by direct invocation.) It's expected to return a value from /usr/include/sysexits.h. Most Red Hat, Fedora and CentOS users know the procmail mailer, as it's used for local delivery. Based on properties of a message, another mailer may be chosen, either from the config file or from the mailertable map file. The mm-handler README explains how to set up a match on the domain name.

If so, it seems that rather than just dropping a 'bad' message as mm-handler seems to do when $BounceUnapproved = 0; and $BounceNonlist = 0;, wouldn't it be better to exit with a failure status.

Good idea. EX_NOUSER (67) would be a good code to return. Does Perl have a module that defines these codes symbolically? I didn't see anything at CPAN, but I found one here:

<http://pub.ks-and-ks.ne.jp/prog/SysExits.shtml>