3

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.

Improve this question
4
  • 2
    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. Commented May 8, 2012 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... Commented May 9, 2012 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. Commented May 24, 2012 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 Commented Jun 28, 2012 at 2:59

1 Answer 1

Reset to default
2

(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.

Improve this answer
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.