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

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

Am 22.11.2011 03:42, schrieb Jonathan Kamens:

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

> The problem with this approach, if I am understanding what you are
> saying correctly, is that we have multiple remote mailboxes /being
> delivered to the same local user account./ If the MDA setting were
> specific to the remote account being queried that would work fine, but
> if it's specific to the local account, it's problematic.

Well, "user" is as opposed to "server", and was referring to fetchmail
rcfile syntax.  What I actually mean is that it's specific to the
upstream server's user, or account.

You should be able to go about something like (untested fragment!):

#------------------------------------------
# one server with two accounts to be polled
poll someserver.example.org proto pop3 uidl
user john pass 123 is joe.sixpack mda "/my/fancy/script john" ssl
user jack pass 456 is joe.sixpack here mda "/my/fancy/script jack" ssl
#...

poll otherimaptoaster.example proto imap
user joe pass "really@ strange!password" is joe.sixpack here
mda "/my/fancy/script joe@other"
#------------------------------------------

Would that work for you?  All three accounts from two servers map to the
same local user, but have a distinct mda option, so I hope this meets
your needs.

> P.S. I apologize for the misleading Subject line I used to start this
> thread. When I started writing my message to the list, I was thinking in
> terms of modifying fetchmail to allow arbitrary headers to be added to
> messages before delivery, but my thinking evolved as I wrote the message
> and I obviously ended up proposing something different, but I forgot to
> go back and update the Subject. I'm not going to change the Subject line
> now, though, because that would just confuse everybody's threading. :-)

Would it really?  I rely on In-Reply-To: and References: headers for
threading...

But generally I'm open to provide filtering through an external command
should the need arise, possibly combined with decisions as to the
transient/permanent error or deliver or drop-silently.  I'm not sure
that it needs to be more specific like that because there are tools like
maildrop's reformail that can modify message headers.