This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Re: SMTP Problem - rejected after DATA

When I check through my smtp logs, i get the following error:

2004-Mar 10 12:06:09 (none) exim[15143]: 2004-03-10 12:06:09 1B12TR-0003wF-8l H=(serlinux15.xxxxx.xx.xx) [xxx.xxx.48.17] F=<> rejected after DATA: malformed address: ]>\n may not follow "Holly Rodrigues" 
2004-Mar 10 12:06:09 (none) exim[15143]: [1\41] 2004-03-10 12:06:09 1B12TR-0003wF-8l H=(serlinux15.xxxxx.xx.xx) [xxx.xxx.48.17] F=<> rejected after DATA: malformed address: ]>\n may not follow "Holly Rodrigues" 
2004-Mar 10 12:06:09 (none) exim[15143]: [2\41] Envelope-from: <>
2004-Mar 10 12:06:09 (none) exim[15143]: [3\41] Envelope-to: 
2004-Mar 10 12:06:09 (none) exim[15143]: [4\41] P Received: from [xxx.xxx.48.17] (helo=serlinux15.xxxxx.xx.xx)
2004-Mar 10 12:06:09 (none) exim[15143]: [5\41] ^Iby mail.xxxxx.co.uk with esmtp (Exim 4.22)
2004-Mar 10 12:06:09 (none) exim[15143]: [6\41] ^Iid 1B12TR-0003wF-8l
2004-Mar 10 12:06:09 (none) exim[15143]: [7\41] ^Ifor kelly@xxxxx.co.uk; Wed, 10 Mar 2004 12:06:09 +0000
2004-Mar 10 12:06:09 (none) exim[15143]: [8\41] P Received: from sernt14.xxxxx.xx.xx ([xxx.xxx.48.26])
2004-Mar 10 12:06:09 (none) exim[15143]: [9\41] ^Iby serlinux15.xxxxx.xx.xx with esmtp (Exim 4.24)

...with the rest of the headers following.

Why does it reject the mail and how do i stop it?

I don't have address or sender verification switched on, or block rcpt hacks, or mime checking.

And the mail is all legitimate mail as well.
  


This thread was automatically locked due to age.
Parents
  • Can the person reproduce the error by sending another mail?

    If so, it is because a piece of mailer software at AOL is not doing something according to RFC. I had this problem once with AOL (a different error though: a duplicate To was being generated, which is also not RFC). I called them up, and believe it ot not they fixed it within a couple of days. So if it is reproduceable, you will have to do the same.

    P.S. There are no AntiVirus mail appliances outside the firewall, right? That could alter the headers. Your ISP could even be doing it unbeknownst to you (but that is unlikely, since it would be an added expense for them...)

    I would guess that a temporary fix would be for her to remove the newline from her display name (if that's where it's slipping in and can be altered in AOL's powerful client software...).

    P.S. AOL does seem to be getting better with their software now; rather than rolling their own ersatz, they are starting to adopt stuff that works, like WinAmp...
  • Unfortunately, I can't get her to change the way she sends email, or get the mailing list hoster (a university) to alter their software.

    The email was sent by her to a mailing list that one of my users is subscribed to. I believe the mailing list software is majordomo.

    I've had other problems of this nature with a different mailing list, hosted by the same university.

    Nope there are no mail appliances outside the firewall that I control. The university does spam filtering and anti-virus checking on all mail but the problem only seems to affect messages sent via majordomo.

    I tried searching the exim lists as well to see if there was a fix but I couldnt find one.

    If this carries on I'll have to switch the mail relay off as I can't really afford to have false positives [:(]    
  • Please do understand, though. It's probably not that Exim is being too 'picky'; the agent sending mail is not adhering to RFC (header lines cannot contain embedded newlines). If possible, get them to fix it. Otherwise, if your mail relay software 'guesses' as to what they meant to say, you start having a Tower Of Babel...

      
  • Is there a way to force exim to accept messages from certain domains or users then?

    I didn't think that using the whitelist function would stop this type of thing.   
  • There are no overrides for the SMTP parsing, since it's RFC spec. If it was a do-or-die, you could modify and recompile the source. But that's not practical due to the fact that the next Exim binary update would supersede your compilation...
      
  • Maybe nothing to help in the actual problem, but the same happened to us when we upgraded from ASL3 to ver 4.
    The problem was a specific MUA, FoxMail which was doing the same non-RFC thing. Fortunately there is a workaround available for that (you can find it from Google groups).
    I would also recommend trying to do something about non-standard sender if possible.   
  • Do you mean there is a fix for the sending agent, or for exim?

    I've tried looking in google groups and I can't seem to find a fix.

    If it's possible, can you post a link?

    Thanks  
Reply Children
No Data