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