-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IETF lists do From-munging, including within multipart/signed MIME part contents, in violation of RFC 1847 §2.1 #3487
Comments
To be clear, the reason that this is a problem is that the cryptographic signature on the message is broken. |
I just tested another mail path to the archive, using the ietf-smtp@ietf.org mailing list from protonmail, and confirmed that from-munging is happening there too: https://mailarchive.ietf.org/arch/msg/ietf-smtp/C1r1ssVW21z3lpSJNV2swPy15z4/ This second message was unsigned, so the from-munging it's not a violation of RFC 1847, but it would still be nice to avoid the from-munging, which shouldn't be necessary in a modern mail setup. |
From munging is an ancient hack dating from the 1970s because the Unix mbox format uses "From " as a separator line. |
Yep, i am aware of the history of From munging and its relationship to mbox. If you have to from-munge because you're storing in mbox format, there are reversible ways to do so (e.g. insert an additional ">" whenever you encounter the regex |
The backing store is individual files (maildir format IIRC) See https://mailarchive.ietf.org/arch/msg/secdir/BDhtxVilF8J0y2eQg4P5a-xJx0E/ for an example of the damage inside the message. Note that this particular Also note the lack of the escaping in the source material at https://datatracker.ietf.org/doc/review-ietf-6lo-use-cases-12-secdir-lc-sparks-2022-04-05/. The damage before it lands in storage is of note:
Something in the mailchain is doing an unexpected thing that it shouldn't. |
thanks for digging into this, @rjsparks (and i'm sorry to see that one of your messages got bit by this too)! If this issue needs to be reassigned to some other component of IETF infrastructure (before it hits the mail archive) that would be understandable too. If that happens, please let me know where it's being reassigned so i can follow along with the fixing. I'm happy to help test any proposed fix if there's a way for me to do that. |
This comment was marked as spam.
This comment was marked as spam.
It looks like this is happening prior to message archival. A test message did not get munged: Also, we have raw bytes that are submitted for archival for all recent messages. On inspection, recent examples of munged Froms show the corruption in the submitted data: |
On March 6 call, discussed building a container to test the email chain for From munging, might be related to DMARC rewrites. |
This is caused by Postconfirm's (Python2) use of message.as_string() mangling the From |
Message-ID
41f938ab-4fa6-414e-bd0e-2a932c04fb95@fifthhorseman.net
appears at the mail archive at: https://mailarchive.ietf.org/arch/msg/openpgp-dt/6mqbfSI5OVmVtF9R6i2zSSjYx4M/This is the original message in
message/rfc822
form.Note that
From a simpler
in the original is rendered as>From a simpler
in the archive. This appears to be From-munging.In this case, it is also breaking §2.1 of RFC 1847 which reads:
The copy of the message i received as an e-mail message (which has the
Archived-At
header field) also has been From-munged. This may be an issue that happens before the mailarchive gets to touch the message -- i can't see deeply enough into the IETF mailing list infrastructure to tell -- but i'm quite sure that the message is not From-munged when it is injected into the IETF's SMTP server. If you think the problem is happening before the message reaches the mailarchive, feel free to redirect this bug report somewhere else.The text was updated successfully, but these errors were encountered: