Description of problem: When email is received from certain servers (in our case, 2 regular partners running Microsoft Exchange), it is rejected. syslog shows "cataddr: string too long" Version-Release number of selected component (if applicable): sendmail-8.13.1-3.3.el4.i386 How reproducible: 100% Steps to Reproduce: 1. Email to a user at the remote site who has an out-of-office autoreply 2. Wait for reply 3. Actual results: Mail not delivered, remote user gets rejection message, syslog shows catadr error Expected results: Mail arrives Additional info: sendmail.org shows some information relating to this bug in the changelog for sendmail 8.13.2. sendmail 8.13.8-2 built from RHEL 5.3 SRPM does not have the problem The problem only happened for us when using TLS which was negotiated during SMTP. If I disabled TLS, the problem did not occur. I was then able to capture the SMTP packets, but could see no formatting problem with the message - no bare CR, no long lines. Replaying the message through openssl s_client starttls did not trigger the problem. The only odd (but legitimate) feature was that the message body (nominally English text) was base-64 encoded UTF-8 So I do not understand why the error occurs, only that upgrading sendmail beyond the last RHEL4 version cures the problem. I have no way to reproduce the problem apart from corresponding with users at the 2 sites in question.
I have the same problem. It looks like it's fixed in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=131179 It's fixed in sendmail 8.13.2 (http://www.sendmail.org/releases/8.13.2)
This is probably problem in MS Exchange configuration: http://www.mmmug.co.uk/blogs/nweb/archive/2009/03/28/26631.aspx I can't verify it... See you PetrR
The cataddr error is caused by TLS negotation phase between Exchange and Sendmail. There is upstream errata (2004-08-24) and patch available for cataddr errors: http://www.sendmail.org/releases/8.13.1 http://www.sendmail.org/patches/parseaddr.c.cataddr.8.379 This patch was also merged to sendmail-8.13.2 by upstream and I assume it is the same piece of code as described in sendmail-8.13.2 changelog mentioned in comment #1. This patch is applied from sendmail-8.13.1-2.el4 up, thus this error couldn't appear. Please could you reinstall sendmail-8.13.1-3.3.el4 and recheck?
Hello. I can still see this error messages in my logs, but as you wrote - it caused by MS Exchange. I'm using sendmail-8.13.1-3.3.el4 and I can't reinstall it. As far as I remember MS Exchnage can be configured to work well with Sendmail using TLS negotiation so you can close this ticket. Thank you PetrR
OK, thank you, closing.