-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
$Conf{EMailFromUserName} is overridden by "auto_from on" in /etc/msmtprc #27
Comments
Oh, if you do decide to update entrypoint.sh to address this, it'd be nice to have an environment variable that allows users to enable msmtp logging, perhaps defaulting the logfile to /home/backuppc/msmtp.log if no path is provided. As I was changing it by hand anyhow, I've also modified /etc/msmtprc to include this line: logfile /home/backuppc/msmtp.log |
Hello @toggoboge! Just to let you know that I saw your issue and did not forgot it. I will handle it as soon as I have some time. |
Thanks. Maybe /var/log is a better location for a logfile. |
Hello @toggoboge, I finally got the time to handle this issue. So, I improved the logic to fit the usecase you described here. Basically:
|
Thanks Adrien. Cheer, Brian
…On Sun, Mar 1, 2020 at 4:56 PM Adrien Ferrand ***@***.***> wrote:
Hello @toggoboge <https://github.com/toggoboge>, I finally got the time
to handle this issue.
So, I improved the logic to fit the usecase you described here. Basically:
- all logs from msmtp are now stored in /var/log/msmtp.log, and also
in supervisord stdout. I hope this will help a lot to debug mail issues
- also, when SMTP_MAIL_DOMAIN is empty (the default), msmtp does not
try to rewrite the envelope-from in mails generated by backuppc. So
$Conf{EMailFromUserName} will be used, not overwritten. If
SMTP_MAIL_DOMAIN is set, the envelope-from will be overwritten to
***@***.***_MAIL_DOMAIN, like before.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27?email_source=notifications&email_token=AIWUU7FDPICAKRNMWOINLKDRFKHSDA5CNFSM4ISYE4R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENNELZQ#issuecomment-593118694>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIWUU7FOM32ZSCYJKKR5BVTRFKHSDANCNFSM4ISYE4RQ>
.
|
I am running the BackupPC v4.3.1 version of the container.
BTW, below I have obscured my domain as 'mydomain.com'.
$Conf{EMailFromUserName} is overridden by "auto_from on" in /etc/msmtprc, meaning the configured from-address is not used in outgoing emails.
Using SMTP_HOST & SMTP_MAIL_DOMAIN environment variables, I have configured the backuppc container to send emails via a local SMTP relay container (docker pull namshi/smtp).
I've created a Gmail account, [email protected], for use by the SMTP relay container. The Gmail account has also been setup with an alias, [email protected], and emails sent by a small python script from this address via my local SMTP relay are successfully received as coming from [email protected].
In the backuppc container, I have set $Conf{EMailFromUserName} to [email protected].
When I try to send a test email to [email protected] from inside the container, I see the following:
This successfully sends emails via my local SMTP relay. However, the mails are always received as coming from [email protected].
In spite of [email protected] being used on the sendmail command-line, I see the following in the headers:
From: [email protected]
X-Google-Original-From: [email protected]
Gmail is not honouring the from-address because [email protected] has permission to send emails from [email protected], but not from [email protected].
I think this is happening because the "auto_from on" setting in /etc/msmtprc is causing msmtp to generate the from-address from the Linux username, 'backuppc' in this case. This causes the configured $Conf{EMailFromUserName} to be overridden, and [email protected] is used as the from-address instead of [email protected].
Manually changing "auto_from on" to "auto_from off" in /etc/msmtprc has fixed this for me (at least for test emails - I haven't yet checked other emails auto-sent by BackupPC), and the test email sent by the BackupPC_sendEmail command above, is now received by [email protected] with the from-address is correctly set to [email protected].
The text was updated successfully, but these errors were encountered: