I've faced with a problem with elog.. it can't sent email because of an invalid mail from address... error is: "!!! An error occured while trying to send logmail:\n(553, '<portage> Invalid mail address, must have a domain part', 'portage')" I patched mod_mail.py to manage a real address (or a fake one but still in a valid form)... check attachment for the patch it's one line patch) this adds PORTAGE_ELOG_MAILFROM as user variables - to let people write a good email address for them.
Created attachment 75462 [details, diff] oneline patch
this bug hit me too, however i was not able to fix it with your patch. i think this is because of line 48 in mod_mail.py: myconn.sendmail("portage", myrecipient, mymessage.as_string()) as you see, portage is still hardcoded there. I replaced it with "portage@blubb.ch" and got my mails :) note that the mail does include 'Return-path: <portage@blubb.ch>' but it'd be nice if portage could also set 'From: <portage@blubb.ch>', otherwise chances are high that the mails are marked as junk
Created attachment 79186 [details, diff] Added setting PORTAGE_ELOG_MAILFROM to both return-path and from field You need to define which mail address to portage should send from by adding: PORTAGE_ELOG_MAILFROM="portage@domain.name" to /etc/make.conf portage@domain.name may be any mail address that the smtp mail server accepts as valid.
Any rough estimates, about when this patch might get applied?
*** Bug 125223 has been marked as a duplicate of this bug. ***
Created attachment 82030 [details, diff] another patch Here is another patch. It sets the correct sender depending on the mymailhost var with the least amount of configuration needed.
I wonder why I get about one portage update in ~x86 per day, yet have to see anything on this front. Is the whole elog-system being reworked?
Okay, so version 2.1_pre9-r4 fixes a lot of the issues. But there's still no From: set (header field, not envelope from). Adding this is trivial. Just add mymessage["From"] = myfrom below mymessage["To"] = myrecipient in /usr/lib/portage/pym/elog_modules/mod_mail.py Otherwise, some mail server setups refuse to accept the mail. Yes, this is according to RFCs. That most mail servers don't care doesn't mean it's best common practice.
(In reply to comment #8) > Okay, so version 2.1_pre9-r4 fixes a lot of the issues. > > But there's still no From: set (header field, not envelope from). Adding this > is trivial. As long as PORTAGE_ELOG_MAILFROM is set the From header field is set for me. 2.1_pre9-r4 fixes all issues for me so as far as I'm concerned this bug is resolved.
Will one of those patches find its way into portage 2.1?
fixed some time ago.
No it's not fixed. From: in header is *still* unset as per comment #7 . At least in 2.1_rc2-r3.
Sorry. #8.
I suppose I should have responded sooner but I was waiting to see what would develop. I have to agree with Tobias. If mail is going off-server, it must append at least the domain name. The PORTAGE_ELOG_MAILFROM is a hack that must be configured on a server on any kind of modern network. If I change the the server name, then I must remember to change this setting or things will break. If I assign the server name via DHCP, I must remember to connect to the server and fix this setting or things will break. Features should work properly in the default state. The alternative is to run a proper mail server on the host and forward portage mail from it. I don't know why I should be forced into running a full mail server just to make use of this feature. If portage at least called /bin/mail, it would work properly whether one was using postfix or SSMTP or any other RFC compliant mail daemon. I would be happy if the setting took variable substitution like "PORTAGE_ELOG_MAILFROM=portage@`/usr/bin/hostname -f`" but it doesn't. Thanks for reading.
This is still not fixed, yet I've just read the announcement of 2.1 final. Please tell me if I'm an idiot, because I sure feel treated like one.
This bug was supposedly fixed in svn r3014. Doesn't PORTAGE_ELOG_MAILFROM work as per comment #9? Comment #14 seems like an enhancement request that is worthy of a new bug.
Re #16: It *seems* to me that the poster of #9 has some setup in which the header field is added by the (local?) MTA according to the Envelope-From. That isn't the case for me and the Mailserver I use (and am forced to use) does not set that field (and late-rejects mails that don't a valid From:). My fix (as per #8) fixes it for me, but it's not that great having to edit the mod_mail.py script every time I update portage.
(In reply to comment #17): What did you set PORTAGE_ELOG_MAILFROM to in /etc/make.conf? The mail server of my ISP still rejects the mails with the "Sender address rejected: need fully-qualified address" if I don't set PORTAGE_ELOG_MAILFROM in /etc/make.conf. I am not really sure what kind of setup you think I have (didn't understand it) but I think you are wrong. :)
I set it to fully qualified address that the MTA I'm using knows about (or rather: its validity). When I send mail, the complaint I get from the Server is as follows: "!!! An error occured while trying to send logmail:\n(550, 'no valid sender in Sender:, Reply-To:, or From:')" Looking at the traffic with ethereal shows that indeed there's no From: header in the mail. Many MTAs don't care about it, but it's still in violation of RFC 2822 (Part 3.6.2., "Originator fields").
As an illustration (true mx name edited out due to other concerns): 220 mx.someisp.invalid ESMTP Exim 4.61-RC1 Sat, 10 Jun 2006 11:49:16 +0200 MAIL FROM:klausman@schwarzvogel.de 250 OK RCPT TO:klausman@schwarzvogel.de 250 Accepted DATA 354 Enter message, ending with "." on a line by itself Subject: Foo To: klausman@schwarzvogel.de haha! . 550 no valid sender in Sender:, Reply-To:, or From: MAIL FROM:klausman@schwarzvogel.de 250 OK RCPT TO:klausman@schwarzvogel.de 250 Accepted DATA 354 Enter message, ending with "." on a line by itself Subject: Foo To: klausman@schwarzvogel.de From: klausman@schwarzvogel.de haha! . 250 OK id=1Fp06O-0002In-D3
Added in svn r3483
Reopenning until svn r3483 has been released...
Had a peek at the repo. Looks great. Thanks.
This has been released in 2.1.1_pre1.
