--- in DMARC From: rewritings
Hello,
the DMARC Mitigation action “Replace From: with list address” is evaluated in mailman/handlers/dmarc.py:munged_headers(). In the case, where From: is a non-member email address, without display part, which non-member may post, this happens:
realname = email realname = re.sub(r'@([^ .]+.)+[^ .]+$', '---', realname) with _.using(mlist.preferred_language.code): via = _('${realname} via ${mlist.display_name}') display_name = str(Header(via, mlist.preferred_language.charset)) value = [('From', formataddr((display_name, mlist.posting_address)))]
In short, if a@b is a non-member, who may post to mailing list “E c@d”, and b is DMARC-protected, the final distrubuted email will have
From: "a--- via E c@d" Reply-To: a@b
compare to the IETF mailing lists, which would send: From: a=40b@d where a and b are from a@b, d is from c@d
The bottom of https://answers.uillinois.edu/illinois/page.php?id=86787 describes the mitigariton options offered by Sympa:
display name From: User Name listName@lists.illinois.edu
display name and e-mail From: “User Name” (userEmail@address.com) < listName@lists.illinois.edu >
email “via Mailing List” From: “User Name” (userEmail@address.com via listName Mailing List) listName@lists.illinois.edu
name “via Mailing List” From: “User Name” listName@lists.illinois.edu (the website likely means:) From: “User Name via listName” listName@lists.illinois.edu
As can be seen, the other MLMs do not replace domains with --- . I find ugly the --- , inserted by mailman. In my real-world case the From: is aaa@example.org, the ML name is aaa@l.example.org (localname is the same, the domains are different). The result is:
From: aaa--- via Aaa aaa@l.example.org
So there is twice trippe-A and @example.org disappeared. Mentioning twice AAA in the display name in this case really has to added value.
That said, I propose removing now the line
realname = re.sub(r'@([^ .]+.)+[^ .]+$', '---', realname)
and in the future offer as options: From: User Name listName@lists.illinois.edu From: “User Name” (userEmail@address.com) < listName@lists.illinois.edu > From: “User Name” (userEmail@address.com via listName Mailing List) listName@lists.illinois.edu From: “User Name via listName” listName@lists.illinois.edu
Дилян Палаузов writes:
realname = re.sub(r'@([^ .]+.)+[^ .]+$', '---', realname)
The obvious hack is to change '---' to '', which you can do locally.
I'm not sure why we use '---', since it's not informative. I will have to see if one of the other devs knows, or maybe there's something in the history.
compare to the IETF mailing lists, which would send: From: a=40b@d where a and b are from a@b, d is from c@d
That's elegant, but I suspect that it would be confusing to anyone who isn't an email hacker.
In my real-world case the From: is aaa@example.org, the ML name is aaa@l.example.org (localname is the same, the domains are different). The result is:
From: aaa--- via Aaa aaa@l.example.org
So there is twice trippe-A and @example.org disappeared. Mentioning twice AAA in the display name in this case really has to added value.
Of course there's added value. The first "aaa" is a necessary hack to identify the author, while the second is the name of the list. That they are the same is just an accident (unless the list owner is "aaa", in which case they should just add their display name). You could argue that since the mailing list's display name is usually just a capitalized version of the local part of the posting address, it's unnecessary, but that turns out to be untrue since some common MUAs suppress addresses in the display, leaving only the display name.
and in the future offer as options: From: User Name listName@lists.illinois.edu From: “User Name” (userEmail@address.com) < listName@lists.illinois.edu > From: “User Name” (userEmail@address.com via listName Mailing List) listName@lists.illinois.edu From: “User Name via listName” listName@lists.illinois.edu
None of these work in the case of interest since they assume the display name is available, and I don't see enough value in additional options to do this myself. FWIW, I don't think any of the other core developers would be interested in doing it, either. You could submit a patch, but I can't promise it would be accepted, unless one of the core devs here expresses an interest in it.
I think it's definitely possible to make a case for changing the default here, but if we're going to offer options, I think we would probably allow the admin to specify a format string rather than offering multiple fixed formats. And if we're going to change at all, be prepared for a long bikeshedding conversation because (1) the current approach works for everybody, although it is occasionally ugly, and (2) we need to be careful that the result is readable and informative in almost all MUAs.
Steve
On 3/17/22 10:19, Stephen J. Turnbull wrote:
Дилян Палаузов writes:
realname = re.sub(r'@([^ .]+.)+[^ .]+$', '---', realname)
The obvious hack is to change '---' to '', which you can do locally.
I'm not sure why we use '---', since it's not informative. I will have to see if one of the other devs knows, or maybe there's something in the history.
There is history. Some of this is embodied in comments at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/dmarc.....
In particular, we don't include the original From: @domain because of goal #2. We use --- to imply that something is missing. Perhaps ellipsis would have been a better choice, but we didn't want anything that even hinted at a domain.
Mark Sapiro writes:
On 3/17/22 10:19, Stephen J. Turnbull wrote:
Дилян Палаузов writes:
realname = re.sub(r'@([^ .]+.)+[^ .]+$', '---', realname)
The obvious hack is to change '---' to '', which you can do locally.
I'm not sure why we use '---', since it's not informative. I will have to see if one of the other devs knows, or maybe there's something in the history.
In particular, we don't include the original From: @domain because of goal #2 [in dmarc.py]. We use --- to imply that something is missing. Perhaps ellipsis would have been a better choice, but we didn't want anything that even hinted at a domain.
OK, that makes some sense. Here's goal #2:
# 2) the original From: address should not be in a comment or display
# name in the new From: because it is claimed that multiple domains
# in any fields in From: are indicative of spamminess. This means
# it should be in Reply-To: or Cc:.
I don't recall there being documentation of this claim. I certainly believe it happens at least occasionally (I know several mail admins who will implement any filter that might eliminate 1 or more spams in the next decade ;-). But is it really a major problem?
I'm coming around to the idea of a general format language for configuring various Mailman-generated texts with a bunch of standard codes (like strftime). There are too many "minority" problems like the OP's (and I suspect "multiple addresses are spam" for that matter) for me to be comfortable ignoring the set, but on the other hand the number of options we'd have to provide to satisfy 1/10th of them would be insane, and unpopular with 99% of the folks considering changing the default.
I am considering adding this as a project to GSoC. Comments welcome.
Steve
Hello,
In particular, we don't include the original From: @domain because of goal #2 [in dmarc.py]. We use --- to imply that something is missing. Perhaps ellipsis would have been a better choice, but we didn't want anything that even hinted at a domain.
OK, that makes some sense. Here's goal #2:
# 2) the original From: address should not be in a comment ordisplay # name in the new From: because it is claimed that multiple domains # in any fields in From: are indicative of spamminess. This means # it should be in Reply-To: or Cc:.
I don't recall there being documentation of this claim. I certainly believe it happens at least occasionally (I know several mail admins who will implement any filter that might eliminate 1 or more spams in the next decade ;-). But is it really a major problem?
I'm coming around to the idea of a general format language for configuring various Mailman-generated texts with a bunch of standard codes (like strftime). There are too many "minority" problems like the OP's (and I suspect "multiple addresses are spam" for that matter) for me to be comfortable ignoring the set, but on the other hand the number of options we'd have to provide to satisfy 1/10th of them would be insane, and unpopular with 99% of the folks considering changing the default.
“It is claimed that multiple domains in any fields in From: are indicative for spamminess” is a rumour, which does not account for real-world feasible use cases.
Since other MLMs have the option to include the full original-From: address in the display-part of the From: header, mailman shall have this option, too.
Greetings Дилян
I have just created https://gitlab.com/mailman/mailman/-/issues/989 to help deal with nonmember issues. Changing the munging of the ultimate display name is not included in that issue.
participants (3)
-
Mark Sapiro -
Stephen J. Turnbull -
Дилян Палаузов