Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

The level of enlightenment by a colleague to find a pattern in this has saved me from a new depth of madness. My hope is that the brain trust here can now tell me why...

The Scene: We have several generic mail IDs with procmail setup to redistribute mail based on the original recipient. For example, mail sent to generic_ID1 goes to staff1,staff2; mail to generic_ID2 goes to staff3,staff4; et cetera...

GENERIC_ID1_RECIPIENTS="staff1@domain,staff2@domain"

:0
* ^TO.*generic_ID1
! $GENERIC_ID1_RECIPIENTS

The Problem: Mail was being truncated, seemingly at random. The pattern finally discovered showed that it occurred when a sentence ended with a period at column 76 and a hard carriage return: not at column 75 or 77; not at column 76 with more text to follow on that same line. Any text following that period was lost.

Addendum: we've just seen it reoccur (and reproduced it) with a period at column 226. I am gobsmacked.

I am able to confirm that procmail receives the message whole by copying the message before redelivery:

:0c                       # note: 'c'
* ^TO.*generic_ID1
! $GENERIC_ID1_RECIPIENTS

I believe that sendmail may be truncating it upon redelivery but I'm unsure how to diagnose or prove that (I am not a sendmail admin, just a procmail user).

The problem is entirely reproducible.

The Questions: Why is this happening and how can I fix it?

Much thanks.

EDIT: Updated title and tags. The solution is in the comments.

share|improve this question
1  
I can explain part of the why: something somewhere is wrapping your email to 75 columns (76=1*75+1, 226=3*75+1), and a line containing only a . is an end-of-mail signal in some ancient mail processing systems. I don't know what's doing the wrapping and truncating or how to make it stop. –  Gilles May 8 '12 at 22:54
    
Thanks. You offer another interesting piece of data there. Even so, I'm unaware of any text wrapping option that ignores word boundaries; if it is, it's doing so pretty severely at the hard 75. Puzzled beyond belief... –  Joe Creighton May 9 '12 at 19:14
    
I found this link but I don't know if this would be part of your procmail system: newsgroups.derkeiler.com/Archive/Comp/comp.mail.sendmail/… . A very long shot. By the way, mail is still terminated by <CRLF>.<CRLF> That's not ancient. See RFC5321. –  John S Gruber May 24 '12 at 22:39
    
I'm not sure what the problem is, but leaving the answer split across a bunch of comments is kind of silly, so I posted a community-wiki answer –  Michael Mrozek Jun 28 '12 at 2:59
add comment

1 Answer

up vote 1 down vote accepted

(Converted from question comments)

There were actually three parts to this equation: sendmail, procmail, and Exchange:

  • Exchange: on accepting a piece of mail for delivery, it appears to reformat a plain text message, encoding and wrapping its lines to 75 characters.

  • sendmail: An old (but known) behaviour was being followed in that mail with a bare period on a line was interpreted as end-of-message and then delivered, effectively truncating the actual mail body.

  • procmail: According to docs, it's supposed to invoke sendmail with flags that force it to ignore bare periods. It was not doing this and not honouring explicit config file directives, either. The short term solution: passing -oi -OIgnoreDots=T to all redelivery recipes. The long term solution: an upgrade of our site's procmail installation which now honours config settings and ignores the bare period (passed flags are no longer required).

The hard wrap came into play because, when Exchange encoded the previously plain text message, it introduced =20 which probably allowed the period to be wrapped by itself and left alone on a line.

share|improve this answer
    
Thanks for the edit, Michael. –  Joe Creighton Jun 28 '12 at 14:12
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.