I can't help you with the passive-probe problem, but I can say that going into the exim spool and manually editing the flawed email addresses in the blocking message will clear the queue out real quick.

I don't know if the problem is specific to exim or not. I suspect not but I don't know that.


On Wed, Nov 6, 2013 at 1:52 PM, Margaret King <[log in to unmask]> wrote:
We have the "mailto" problem here too. Someone here said it was from list owners using Rich Text Format. I try to get people to do their list management through the web interface since plain text seems to be a foreign concept now.

In our case Listserv can usually survive one or two, but if a lively discussion happens on a list with five or six of them, it will have to be restarted if we don't catch it right away. I did not realize this was an Exim-specific thing - other MTAs deal with those more gracefully apparently?? The cpu usage goes up to some extreme number and the smtp workers start dying off. And I am pretty sure the people in question don't get the mail because when I try to go in and "change" them I often find that the plain version is also on the list, which makes me think they complained of not receiving the mail and were added again, but correctly the second time.

Nice to know someone else is using Exim!! I don't suppose you have a way to deal with the munged owner addresses the passive probe wants to use? (Been looking for an Exim-specific solution for that for a while....)

Margaret King
Michigan State University


Quoting John Adams <[log in to unmask]>:

Some of them I know the provenance of, mostly people uploading bad
addresses via text file imports. Others I suspect wouldn't have gotten in
through version 15.5 but are old artifacts. In any event, this is
essentially self-service for all but a very small number of lists, and the
time and resources it took to scan every list was surprisingly low. My boss
has tasked me with getting them out rather than keeping them out, and I'm
following his lead on it.

The clogging? When one of those addresses gets to exim, it pretty much
comes to a halt. It's grim.


On Wed, Nov 6, 2013 at 10:37 AM, k p <[log in to unmask]> wrote:

You may find it more interesting to research how they are getting into the
lists and study methods for preventing that.

For example, do your lists get populated by bulk import from a student
information system?

How severe is the clogging of queues?  Ordinarily the LISTSERV auto delete
mechanisms would be expected (if configured) to recognize and remove
invalid addresses within a few days on their own - or at least provide each
affected list owner with information via the Daily Error Monitoring Report.



On 11/6/2013 10:42 AM, John Adams wrote:

Sorry. I guess I didn't explain fully.

We found that malformed addresses were clogging our queue. The worst
ones appeared to be in this format:

A Name <[log in to unmask] <mailto:[log in to unmask]>>,


But there were other offenders. So I wrote a little parser for the
*.list files on the server which goes through the lists one by one and
looks for malformed addresses. It skips the header lines and goes
straight to the subscription list. Most of the email addresses I saw
looked either like this:

A Name <[log in to unmask] <mailto:[log in to unmask]>>

or like this:

[log in to unmask] <mailto:[log in to unmask]>


However, somehow a variety of malformed addresses sneak in from time to
time. Most of those are obviously not going to work, but the three types
I've isolated are not, on their face, necessarily invalid. I strongly
believe that <[log in to unmask] <mailto:[log in to unmask]>> will have the

brackets stripped, less strongly believe that AName<[log in to unmask]
<mailto:[log in to unmask]>> will have a space inserted and correctly parsed,

and am pessimistic but uncertain about the possibilities of
[log in to unmask] <mailto:[log in to unmask]><mailto:[log in to unmask]

<mailto:[log in to unmask]>> working.

I've tried to create a test list, but it turns out these malformed
addresses are kind of hard to get into the system. I could probably
figure something out, but the obvious approaches aren't working, so I
thought I'd see if other folks had faced this.


############################

To unsubscribe from the LSTOWN-L list:
write to: mailto:LSTOWN-L-SIGNOFF-[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1


############################

To unsubscribe from the LSTOWN-L list:
write to: mailto:LSTOWN-L-SIGNOFF-[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1


############################

To unsubscribe from the LSTOWN-L list:
write to: mailto:LSTOWN-L-SIGNOFF-[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1



To unsubscribe from the LSTOWN-L list, click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1