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:[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 >> >> > ############################ > > 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