Leaky mailgate?

[rietta]

I am starting to track down a strange issue with my gpg-mailgate. I can have two emails generated to the same address - be it by cron scripts running in the middle of the night for instance.

One of the messages will be delivered encrypted and the other in plain text. The one in plain-text has the X-GPG-Mailgate header set to Not encrypted, public key not found, which is of course rendered by line 106 in gpg-mailgate.py.

These are emails to the same destination address so clearly the key is found, at least some of the time.

I will gather more log data and see if I can troubleshoot the matter. Has anyone else seen this in their own deployments?

[rietta]

I have additional information on this. It appears that the difference is if the email was addressed directly to the destination address, in which case the key is found and the email is encrypted, or if the mail was to a local account that had a .forward file, in which case the email is not encrypted and is forwarded on to the external destination in plain text. In both cases the to line in the email headers indicates the final destination.

My next step, will be to discover why the recipient is not re-evaluated after Postfix processes the .forward file.

[uragit]

I think I see what may be happening. The mail redirected by a .forward file is probably resubmiited back to postfix with the new envelope recipient. The headers will remain the same but the recipient will be different. gpg-mailgate will encrypt based on the envelope recipient, more or less ignoring the headers.

(This is more or less standard mail-transfer-agent (MTA) behavior. Imagine sending a single email to recipients [email protected] and [email protected]. The header will always retain both recipients in the To: field but the message will be delivered to the MTA at gmail for only [email protected], and to yahoo for only [email protected], in both cases with the correct envelope recipient, otherwise an exponential battle of MTAs generating spurious email to each other would result).

But perhaps I'm a little unclear on your exact test. You say you're sending both email to the same address, but only one is affected by the .forward file. If the initial recipients are the same why is only one copy of the email redirecting by the .forward file?

[rietta]

Thanks Martin!

Indeed, that is the conclusion I arrived at last night. The with configuration workaround that I came to was to define the local email addresses as aliases for the final recipient in the /etc/gpg-mailgate.conf. Though, one could conceivably do the same in the /home/gpguser/.gnupg/gpg.conf as well - which is where one defines a recipient group of an alias email that has more than one recipient to whom the message will be encrypted.

As for my exact test, my end goal was to make sure that all emails egressing the system destined to an e-mail address for which there was a public key on file is encrypted. For example, the .forward test came up because I have a small fleet of servers, both my own and that I manage for others. Whenever a background process emails to root, for example, the .forward file redirected the email to my hostmaster e-mail address that is hosted on my actual mail server where I can receive e-mail.

I was noticing the difference because some system service accounts with crontabs had an explicit MAILTO="[email protected]" set while others were emailing the local user that was then being redirected by .forward to [email protected].