Email transition issues update

[IETF Executive Director <[e-mail]>]

The IETF Administration LLC (IETF LLC) recently transitioned IETF mail services to a modern, modular, and containerized infrastructure as explained in an earlier blog post [1].  This transition has resulted in some problems, most of which have now been resolved, with just a few outstanding.  This email provides details of all of the fixed and outstanding problems to assist anyone who has had a problem before.  If you continue to have problems then please contact [e-mail].

The background here is that the IETF LLC commissioned the design and implementation of a new mail infrastructure three years ago but after repeated issues a new contractor was asked to pick up the work and complete it. Unfortunately, there were multiple problems in one core component of the original work that was not rewritten by the new contractor and these problems were not detected before launch.  That was our mistake and my apologies to anyone affected by these problems.

The problems that have been identified and fixed are:

1. Global allowlist used for list moderation did not include confirmed addresses that were not subscribed to any mailing list
The symptom was that a message sent to a mailing list from an address that had been confirmed for posting but was not subscribed to a mailing list was held for moderation by that list.  This was a regression and the global allowlist is now back to being built including all confirmed addresses. 

2. Messages with ‘Precedence: Bulk’ incorrectly dropped 
The symptom was messages with ‘Precedence: Bulk’ being discarded without notification, which primarily affected emails from IANA.  This was a regression and these emails are now accepted as normal.

3.  Incorrect handling of BATV (Bounce Address Tag Validation) addressing 
The symptom was messages sent with BATV addressing being delivered to lists as coming from an address at relay01.ietf.org rather than the correct sender. This was a regression and BATV tags are now back to being stripped as part of the processing chain.  

4.  Incorrect handling of addresses containing uppercase letters
The symptom was that any address already confirmed and on the global allowlist that used uppercase letters was required to reconfirm as it was treated as a new address.  This was a regression and addresses are now back to being normalised to lowercase and that is used to record confirmation status.

5.  Unusual mail sender handling
A few participants send mail to IETF mailing lists in an unusual way and a series of regex rules had been developed to accommodate these.  The symptom experienced was that these messages were not accepted or were mangled.  The regression was that these rules were unreachable in the code, which has now been fixed and they are working as previously. 

6.  Outlook non-quoted names in addresses
The symptom here was the header From: address was accepted in two parts, with an IETF domain being appended to the first instance.  This was a new bug that is now fixed.

7.  Site owner not set on Postorius (the mailman web interface)
The symptom was participants receiving notifications from [e-mail] as the site owner address had been left blank.  Now set correctly.

8.  DMARC failures on list delivery
The symptom here was a message not reaching recipients due to DMARC policy violations.  This was a regression as the IETF mailing infrastructure has for some time rewritten any address that this would happen to but this was no longer happening in all cases.  The bug was related to the number of recipients a message was sent to and is now fixed.

There are two ongoing problems being worked on:

9. Incorrect bounce processing
The symptom here is mailing list owners receiving a large number of notifications that subscribers are being disabled for excess bounces.  Prior to this transition, due to structural limitations in the old infrastructure, bounces were not making it to the list and were not being processed and no addresses were being disabled as a result.  There is therefore a large backlog of addresses that are no longer reachable but are still subscribed to mailing lists that are being worked through by the bounce processing.  However, there is evidence that some of these bounces are incorrect and therefore bounce processing has been disabled and all disabled addresses re-enabled until this is fixed.

Related to this, the use of VERP, which Mailman implements by default, was found to reduce mail processing times by four to five orders of magnitude and so that has also been disabled while investigations are underway.

10.  Excess spam
The symptom here is excess spam getting through.  The new spam system (Rspamd) is still being tuned.


As noted above, if you continue to have mail issues then please contact [e-mail].  If you wish to discuss this transition then please use the tools-discuss list.  Please feel free to contact me directly if you have any questions.


[1]  https://www.ietf.org/blog/email-service-transition-2026-09/

-- 
Jay Daley
[e-mail]
www.ietf.org