AUR web interface

**This is the bug tracker for the AUR web interface.**

Use this tracker to report bugs or make feature requests regarding the behaviour or implementation of the AUR software.
Please read the Reporting Bug Guidelines before filing a new task.

- Please report bugs related to Arch Linux official packages here:
- Please report bugs for [community] packages here:
- For any packages in the AUR contact the maintainer or leave a comment on the package's detail page.

Source Code:

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 Florian Pritz (bluewind) - Sunday, 17 March 2019, 19:50 GMT
Task Type Bug Report
Category Backend
Status Assigned
Assigned To Lukas Fleischer (lfleischer)
Johannes Löthberg (demize)
Eli Schwartz (eschwartz)
Architecture All
Severity Critical
Priority Normal
Reported Version 4.7.0
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


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[]: 550 5.1.7 <>: Sender address rejected: undeliverable address: host[2a01:4f8:160:6087::1] said: 550-5.1.1 <>: Recipient address rejected: User unknown in local recipient table 550 5.1.1 For assistance contact <>. 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 ( (in reply to RCPT TO command); from=<> to=<> proto=ESMTP helo=<>

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

Comment by Florian Pritz (bluewind) - Sunday, 17 March 2019, 19:49 GMT
This doesn't sound like an SPF-related issue to me, but more like your server has the "reject_unverified_sender" restriction enabled. Granted, that doesn't change the fact that our envelope sender doesn't exist.

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 '').
Comment by Michał Górny (mgorny) - Sunday, 17 March 2019, 20:36 GMT
Yeah, sorry, I meant SAV.
Comment by Lukas Fleischer (lfleischer) - Friday, 24 May 2019, 15:56 GMT
Can't we simply add that user and redirect emails to /dev/null?
Comment by Florian Pritz (bluewind) - Friday, 24 May 2019, 16:19 GMT
We can, but if we do then we will never detected bouncing addresses. If we send enough mail that bounces we will eventually get blacklisted for spamming. A way around that would be to let bounces go to someone who disables email delivery to the bouncing addresses.

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:

And here's the mediawiki plugin that implements one version of this:

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?
Comment by Lukas Fleischer (lfleischer) - Friday, 24 May 2019, 16:33 GMT
I would be happy to have a bounce handler but will not have the time to implement that anytime soon.

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.
Comment by Florian Pritz (bluewind) - Saturday, 25 May 2019, 07:05 GMT
I've set up the /dev/null forwarder, but I'd suggest keeping this ticket open until a bounce handler is implemented in the AUR.
Comment by Lukas Fleischer (lfleischer) - Saturday, 25 May 2019, 16:31 GMT
Agreed, thanks!
Comment by Kevin Morris (kevr) - Thursday, 10 December 2020, 17:20 GMT
I'm down; looking into it.