You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The address set by the Unattended-Upgrade::Sender parameter and then extracted by the -t switch of sendmail as defined in _send_mail_using_sendmail() sets the 'From' field in the email header indeed, but this appears to be not enough (or really almost all the same) regarding the successful delivery of my emails to my external email service provider. I always get the error status=bounced ... Sender address rejected: need fully-qualified address (in reply to RCPT TO command)).
The -r sender argument of sendmail however sets the 'Return-Path' and the 'smtp.mailfrom' fields, which in my case are the important ones. So that my emails get delivered at all, I had to change line #1398 in def _send_mail_using_sendmail() in unattended-upgrade from [SENDMAIL_BINARY, "-oi", "-t"], to [SENDMAIL_BINARY, "-oi", "-t", "-r "+from_address],. This might not be optimal as a general solution for everyone, this might break things in some other setups, I don't know about that. However, in my (I would say fairly common) case, this is the only way that sending emails to an external email service provider works at all.
As for the 'From' field, I am not sure what role it really plays other than appearing at the top of the email at the receiving side. Since it can really be anything (without a space and ideally in the format of an email address), I just replaced the line msg['From'] = from_address with msg['From'] = "unattended_upgrades@host.cc" where host is my machine's name and cc can be some country code. Without @host.cc, the email also gets delivered with @host added automatically to it, however if it always lends in your spam folder, give it the above format of a proper email address and add it to your contacts to white-list it.
A generally satisfying solution might have two distinct parameters in the config file corresponding to the above mentioned two parameters instead of having only the Unattended-Upgrade::Sender parameter controlling only the 'From' field, and not setting the parameters at all that are currently accessible only through the -r sender switch of sendmail.
The text was updated successfully, but these errors were encountered:
Yep the current behaviour is very confusing because despite being called Sender in the case of sendmail as you noted it only sets the From field.
It is also confusing that the default config suggests that mailx will be used, when actually sendmail is tried first:
A package that provides 'mailx' must be installed. E.g. "user@example.com"
This is particularly confusing if you are using nullmailer, which has the allmailfrom option which also works the wrong way around. It actually sets the Sender and does not modify the From field: bruceg/nullmailer#72
Therefore at present in order to use unattended-upgrades and nullmailer together you must set both
Unattended-Upgrade::Sender in order to set the From field
Nullmailer's allmailfrom to set the Sender
I think your idea of having two distinct parameters is great and will help make this less confusing
The address set by the
Unattended-Upgrade::Sender
parameter and then extracted by the-t
switch ofsendmail
as defined in_send_mail_using_sendmail()
sets the 'From' field in the email header indeed, but this appears to be not enough (or really almost all the same) regarding the successful delivery of my emails to my external email service provider. I always get the errorstatus=bounced ... Sender address rejected: need fully-qualified address (in reply to RCPT TO command))
.The
-r sender
argument ofsendmail
however sets the 'Return-Path' and the 'smtp.mailfrom' fields, which in my case are the important ones. So that my emails get delivered at all, I had to change line #1398 indef _send_mail_using_sendmail()
inunattended-upgrade
from[SENDMAIL_BINARY, "-oi", "-t"],
to[SENDMAIL_BINARY, "-oi", "-t", "-r "+from_address],
. This might not be optimal as a general solution for everyone, this might break things in some other setups, I don't know about that. However, in my (I would say fairly common) case, this is the only way that sending emails to an external email service provider works at all.As for the 'From' field, I am not sure what role it really plays other than appearing at the top of the email at the receiving side. Since it can really be anything (without a space and ideally in the format of an email address), I just replaced the line
msg['From'] = from_address
withmsg['From'] = "unattended_upgrades@host.cc"
wherehost
is my machine's name andcc
can be some country code. Without@host.cc
, the email also gets delivered with@host
added automatically to it, however if it always lends in your spam folder, give it the above format of a proper email address and add it to your contacts to white-list it.A generally satisfying solution might have two distinct parameters in the config file corresponding to the above mentioned two parameters instead of having only the
Unattended-Upgrade::Sender
parameter controlling only the 'From' field, and not setting the parameters at all that are currently accessible only through the-r sender
switch ofsendmail
.The text was updated successfully, but these errors were encountered: