[fetchmail-devel] Add feature: add header to messages?

[Jonathan K. <ji...@ka...>]

Hello everyone,

We've run into a fetchmail use case which doesn't seem to be easily 
solved with existing functionality, and I'm writing to ask (a) are we 
missing something and (b) if not, would the fetchmail maintainers 
consider accepting a patch to solve the problem?

In a nutshell, our custom MDA wants to see the recipient addresses of 
incoming messages; it's not there anywhere; and we can't figure out any 
scalable way to get fetchmail to provide it to the MDA.

Our .fetchmailrc fetches messages from multiple mailboxes with different 
addresses. These messages are fed into our proprietary application using 
a custom MDA script that we wrote. Our application does different things 
based on which mailbox each message is from.

The mailboxes receiving these messages are often BCC'd, which means that 
the recipient address doesn't appear in To or CC. Furthermore, the mail 
servers we're downloading from unfortunately don't insert 
X-Delivered-To, or Received lines showing the recipient address, or 
anything like that. In short, there's no way to tell from looking at the 
message fed into the MDA what address it was sent to.

We could hard-code a command-line option for the custom MDA command 
identifying the mailbox, but as far as I can tell, that fails if you've 
got more than one account in the .fetchmailrc file, because I don't 
believe it's possible to specify different MDA settings for different 
accounts (am I wrong about that?).

The idea I've come up with is to add a new "id" per-mailbox 
configuration setting to allow the user to specify an arbitrary 
identifier for the mailbox, and a "%I" command-line escape for the MDA 
settings to allow the identifier for the account from which the current 
message originated to be passed into the MDA.

So, my questions are (a) is there a way I'm missing to solve this 
problem, (b) if not, and we implemented the functionality I described, 
would the maintainers take a patch, and (c) if not, is there some other 
way to solve this problem that the maintainers would suggest we 
implement instead?

Thanks,

Jonathan Kamens