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

[Matthias A. <mat...@gm...>]

Am 15.11.2011 14:29, schrieb Jonathan Kamens:

> 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?

Hi Jonathan,

if I understand you correctly, (a) would apply, but as a second line of
defence, I'm willing to consider (b).

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

And configuring a filter on the upstream server isn't possible either?
Sounds like a rather limited service to me.

> 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?).

Yes, you're wrong - luckily ;-) The MDA setting is a user-specific
setting, so you can generate a modified rcfile that uses a distinct mda
script (or arguments) for each user.  Now, that's for the easy case
where you have one destination address per upstream account.  It won't
work with --mda on the command line though.

For more complex cases that can't be solved that way, I'd be willing to
consider patches against fetchmail's 7 alpha versions (the "master"
branch in Git), such as the proposed one.

> 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?

I'd have to ponder a bit about (c) if the (a) doesn't help.

Hope that helps.

Best regards,
Matthias Andree