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, click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1