Restore mail gateway for roundup installations

[ewdurbin]

@rouilj reports on IRC:

EWDurbin, Taggnostr any idea why email to the trackers seems offline? One of the Roundup contributers reported: [issues@roundup-tracker.org](mailto:issues@roundup-tracker.org): host bugs.python.org[167.71.181.142] said: 454 4.7.1 [issues@roundup-tracker.org](mailto:issues@roundup-tracker.org): Relay access denied (in reply to RCPT TO command) happened sometime on Monday. Did anything change there?

[rouilj]

This is a summary of some investigation I did and reported on IRC. I suggest looking at:

https://www.postfix.org/VIRTUAL_README.html#virtual_alias and https://www.postfix.org/VIRTUAL_README.html#mailing_lists

Apparently the flow is: virtual address links the to field: issues@roundup-tracker.org to an internal alias like: roundup_issue_tracker. Then in /etc/aliases you route the internal alias to roundup-mailgw.

 roundup_issue_tracker:  /srv/roundup/env/bin/roundup-mailgw /srv/roundup/trackers/roundup

This does allow email to roundup_issue_tracker@actual_hostname to end up in roundup's tracker. So maybe some internal name like: roundup_tracker_xRzp342Fg would prevent that, but I'm not sure it's a problem in the first place.

One thing I am not sure about is how the UID to run roundup-mailgw is determined. The example they use in the #mailing_lists URL shows a majordomo wrapper that IIRC is set uid. They reference using a transport. This message to the roundup mailing list might provide an idea: https://sourceforge.net/p/roundup/mailman/message/9104452/ by using an alias file owned by the roundup user to execute as the roundup user. Not sure it would work for multiple trackers though.

I'll ask on the mailing list if anybody has a recipe (and get it included in the roundup docs 8-/).

[rouilj]

I think I have a solution here. It looks like salt is installing ~roundup/.forward+zzzz: where zzz is cpython, roundup and jython extensions.

From this I think the following changes will fix the issue:

in /etc/postfix/main.cf (AFAICT /etc/postfix/main.cf.proto is not used) add:

# support email to trackers hosted here.
virtual_alias_domains = bugs.python.org, bugs.jython.org, roundup-tracker.org
virtual_alias_maps = hash:/etc/postfix/virtual

Create /etc/postfix/virtual with the contents:

# after changing this run 'sudo postmap /etc/postfix/virtual'
# Use with ~roundup/.forward+{cpython,jython,roundup} files:
report@bugs.python.org        roundup+cpython
report@bugs.jython.org         roundup+jython
issues@roundup-tracker.org  roundup+roundup

The aliases roundup+... cause the local delivery to use ~roundup/.forward+... files. We need the virtual configuration to redirect user@yyy.org and to a local address for the local delivery process.

This means changes to /etc/aliases or a roundup_aliases file (as mentioned in prior comment) aren't needed as it's handled by the .forward files.

Also we should disable email to report@bugs.python.org with a nice email message. This can be done (but I recommend a different way) by changing ~roundup/.forward+cpython to read:

|"echo 5.7.1 This tracker is in read-only mode. Please use GitHub issues to open a ticket.; exit 67"
# |"/srv/roundup/env/bin/roundup-mailgw /srv/roundup/trackers/cpython"

to return a bounce email like:

Date: Thu, 11 Apr 2024 14:56:07 -0400 (EDT)
From: Mail Delivery System <MAILER-DAEMON@...>
To: user@example.com
Subject: Undelivered Mail Returned to Sender

[-- Attachment #1: Notification --]
[-- Type: text/plain, Encoding: 8bit, Size: 0.5K --]

This is the mail system at host example.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<roundup+cpythont@bugs.nyc1.psf.io> (expanded from <report@bugs.python.org>): This tracker is in
      read-only mode. Please use GitHub issues to open a ticket.

This is nicer than an error from roundup-mailgw, but I am concerned about backscatter since report@b.p.o will generate a notification email from possibly forged envelope/from header rather than rejecting it at SMTP accept time.

So I suggest adding the following to /etc/postfix/main.cf

# reject email to report@bugs.python.org as tracker is read-only.
# PERMIT is the default when end of list is reached.
smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/reject_recipients

and add /etc/postfix/reject_recipients with the contents:

# after changing this run 'sudo postmap /etc/postfix/reject_recipients'

report@bugs.python.org REJECT This tracker is in read-only mode. Please use GitHub issues to open a ticket.

This will reject the submission to the address and the client SMTP transport agent (rather than b.p.o) will generate a bounce message to the submitter without looking at any possible forged envelope/header addresses.

If we go this route, we can remove the entry for report@bugs.python.org from virtual. (I think this is optional, as I believe the rejection will happen first, but it cleans things up.) Also delete ~roundup/.forward+cpython and clean up the salt pillar that creates it, or modify 'salt/bugs/config/instance-forward.jinja' to add a commented out line saying it is disabled. This will prevent confusion in the future.

Can you let me know if this looks good and which option you prefer:

1) bounce via .forward 2) bounce via reject

and I can get things fixed. Also I could use a consult with somebody on how your salt is set up. It's been a few years since I worked with salt and your config is different from how we had things set up.

[ewdurbin]

I got the expedited Delivery Status Notifications and successfully submitted (and closed) an issue on the roundup tracker.

Calling this closed.