"From line" included in attachment headers

RT Developers
1

We use exim4’s ‘pipe’ transport to send email into rt-mailgate on our system. When it does this, the “From line”, which precedes each email, looking something like:

From user@example.com mon feb 03 11:28:53 2025

is left intact, and it ends up in the list of headers on the relevant attachment in RT.

Having that line in the headers causes problems any time RT needs to reconstruct the message, (for example, trying to forward it) because the line will end up in a random spot, breaking the mime hierarchy, or mess it up in other ways.

In trying to fix this once, I patched RT::Attachment::ContentAsMIME so that when it runs into this line, it puts it at the top of the message, instead of a random spot, but I think the real problem is that this isn’t actually an email header, and it shouldn’t be in there at all.

Is this a bug in RT, or in exim, or in my configuration?

2

The line you pasted here is not correctly formatted. It’s not an SMTP header, a colon is missed. Can you check again if the line in the email processed by RT is like you’ve posted here?
What’s your RT version?

3

It is not an SMTP header, that is correct. It is the “From” line which precedes the actual mail in many situations. Normally when mail is delivered locally, the message, including this line, is simply appended to the destination user’s mailbox, and this line itself defines the start of each email. (see Mbox - Wikipedia) - In the case of RT though, it’s being piped into rt-mailgate, still including the line.

RT then uses MIME::Tools to parse the incoming mail. Here’s what its README says about these lines:

  Ignoring non-header headers
    People like to hand the parser raw messages straight from POP3 or from a
    mailbox. There is often predictable non-header information in front of
    the real headers; e.g., the initial "From" line in the following
    message:
        From - Wed Mar 22 02:13:18 2000
        Return-Path: <eryq@zeegee.com>
        Subject: Hello
    The parser simply ignores such stuff quietly. Perhaps it shouldn't, but
    most people seem to want that behavior.

But I don’t know what it means by “ignoring” since it still ends up populating the headers in the ‘Attachments’ table. I guess it just means it doesn’t throw an error? Is my copy of MIME::Tools (Debian, 5.509-1) broken?

Maybe there is something in exim’s config I can change so that the line isn’t included when piping, but I haven’t been able to find it yet.

So, this seems like a bug in RT, because as far as I can tell, I’m using rt-mailgate correctly. It’s a relatively subtle problem, so my guess is many people are affected and just don’t know it. I’d like to know who does NOT see these non-headers in their database, if they look at Attachments.Headers for those incoming mails?

It’s easy for me to see them (in MariaDB/MySQL) with:

SELECT id, REGEXP_SUBSTR(Headers, '(?m)^From .*$') FROM Attachments WHERE Headers RLIKE '(?m)^From .*$' LIMIT 40
4

Okay, I found the solution - the key was searching for “From_” with an underscore, as that seems to be the conventional way to refer to this line.

That line is added by exim as the “message prefix” - to remove it you need to add:

message_prefix =

to whatever transport handles your pipe commands (on my system, this is at /etc/exim4/conf.d/transport/30_exim4-config_address_pipe).

explanation here: Q0612 · Exim/exim Wiki · GitHub

I’m curious if sendmail, qmail, etc has the same problem, and what the solution is for those users.

1 Like