FS#62047 - AUR mail is sent from incorrect address, causing SPF rejection
Attached to Project:
AUR web interface
Opened by Michał Górny (mgorny) - Sunday, 17 March 2019, 19:04 GMT
Last edited by Toolybird (Toolybird) - Sunday, 22 October 2023, 00:17 GMT
Opened by Michał Górny (mgorny) - Sunday, 17 March 2019, 19:04 GMT
Last edited by Toolybird (Toolybird) - Sunday, 22 October 2023, 00:17 GMT
|
Details
I am attempting to register at AUR and I am not receiving
the registration mail. Upon inspecting the SMTP logs (on the
receiving end), I see:
Mar 17 18:51:54 woodpecker postfix/smtpd[25256]: NOQUEUE: reject: RCPT from luna.archlinux.org[5.9.250.164]: 550 5.1.7 <php-aur@archlinux.org>: Sender address rejected: undeliverable address: host mx.archlinux.org[2a01:4f8:160:6087::1] said: 550-5.1.1 <php-aur@archlinux.org>: Recipient address rejected: User unknown in local recipient table 550 5.1.1 For assistance contact <postmaster@archlinux.org>. Please provide the following information in your problem report: time (Mar 17 18:51:52), client (2001:470:ea4a:1:5054:ff:fec7:86e4) and server (orion.archlinux.org). (in reply to RCPT TO command); from=<php-aur@archlinux.org> to=<mgorny@gentoo.org> proto=ESMTP helo=<luna.archlinux.org> This indicates that the mails are sent from an address that does not exist. Effectively, SPF-enabled servers are going to reject those mails and it is impossible for anyone using such servers to register. Please fix the setup to use an existing e-mail address. |
This task depends upon
I'm assigning this to the AUR devs so they can decide if they want to handle bounces or not. If not I'd suggest to set a null envelope sender (sendmail option -f '').
If you want to automate this, you could use something like VERP where the sender address is set to a different value for each recipient. If a mail bounce, you just look at the bounce recipient and then you can check that against your VERP scheme and determine who caused the bounce. Mailman and our wiki do that.
Here's the general description of what VERP is: https://en.wikipedia.org/wiki/Variable_envelope_return_path
And here's the mediawiki plugin that implements one version of this: https://github.com/wikimedia/mediawiki-extensions-BounceHandler
I'm linking that because it's a rather self-contained portion of code and thus probably somewhat easy to read. The theory behind VERP isn't really difficult. The only thing you should probably take care of is that it's not easy/possible for someone to calculate the VERP address of any particular user. Otherwise an attacker could use that to disable email delivery for others. It might also be good to let each VERP address expire after some time.
Do you still want a forward to /dev/null with all of this in mind?
I guess that forwarding the noreply emails to /dev/null is a strict improvement over the current situation anyway? Setting that up should be very little work and improve the situation until somebody steps up and implements a bounce handler.