 |
 |
To add another plug for the philosophy and design of Eudora--although it does not report this error properly to the user, someone who knows the program can use its debugging log to examine the dialog with the server and thus identify the specific address that doesn't work. I don't think that's possible with these other programs we're discussing (with the disclaimer that I don't know the other programs as well, so I might not be aware of an existing feature that allows this). At 11:15 AM 3/25/2004, John Valenti wrote: >I don't want to get bogged down in details. >My point is that something that worked Monday, doesn't today. It is >unfortunate that several of the PC clients don't follow spec. > >But Outlook & Mozilla are pretty common on campus, I would hope the mail >team would at least consider the Exim router patch. It is quite a >problem for faculty & staff to send to a large list of names, then get >the message refused because of a few bad addresses, but have no easy way >of determining which ones are the problem. > >I did the telnet thing yesterday to find our 2 problem students (out of >130), so we are probably OK. And I see that using the webmail client >will identify the bad addresses. But Outlook always wants to hide the >actual addresses behind the given name, so a simple cut and paste into >the web client won't help. > >-John > > >Doug Nelson wrote: > >>... Given what mail.msu.edu returns, , it should be easy for the sender >>to match up the failed recipients with the matching 5xx code. >>It's unfortunate that some of the clients seem not to reasonably >>follow the spec. >