Sending to mangled 'From' addresses.
All,
Due to the DMARC mitigation action ‘Replace From: with list address’, it happens often on my lists that someone sends a message to a mangled address, hoping that the message goes to the person listed as the sender. This happens mostly because the mail clients collect previous addresses and use them when as type-ahead candidates for new messages, which may be unrelated to the lists.
For example, say the mail client captures my address as
“Allan Hansen via <listname>” <listaddress>
then later, when the person wants to send a message to me, the type-ahead puts this string in the ’To:’ field:
“Allan Hansen via <listname>”
and, to make it worse, the actual email address, <listaddress>, is often hidden.
The result is that the email gets sent to the list instead of to me, together with (often) personal and (sometimes) embarrassing information.
Is there a way to reject messages sent to recipients where the name part of the recipient is of the above format, i.e.,
"Allan Hansen via <listname>"
In other words, filtering is done on the name part of the recipient, not the address part.
Should I get onto the other list to request this as an enhancement?
Yours,
Allan
On 5/31/24 22:23, hansen via Mailman-users wrote:
Due to the DMARC mitigation action ‘Replace From: with list address’, it happens often on my lists that someone sends a message to a mangled address, hoping that the message goes to the person listed as the sender. This happens mostly because the mail clients collect previous addresses and use them when as type-ahead candidates for new messages, which may be unrelated to the lists.
DMARC mitigation action ‘Replace From: with list address’ will also
place the poster's address in Reply-To: (or Cc: depending on list
configuration), so a simple reply from a reasonable MUA should go just
to the poster.
For example, say the mail client captures my address as
“Allan Hansen via <listname>” <listaddress>
then later, when the person wants to send a message to me, the type-ahead puts this string in the ’To:’ field:
“Allan Hansen via <listname>”
and, to make it worse, the actual email address, <listaddress>, is often hidden.
If this is the result of a reply and not reply-all the client is not
behaving reasonably.
The result is that the email gets sent to the list instead of to me, together with (often) personal and (sometimes) embarrassing information.
That is a problem with the client, but I suppose such clients are not uncommon.
Is there a way to reject messages sent to recipients where the name part of the recipient is of the above format, i.e.,
"Allan Hansen via <listname>"
You could add a header filter on the To header with a regexp like
^.*via <listname> and the desired action.
Should I get onto the other list to request this as an enhancement?
I don't think that's necessary in this case, as Header filters should do it.
In general, the best way to request an enhancement is to file an issue
with the appropriate GitLab project at https://gitlab.com/mailman
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2024-06-01 09:49:54 -0700 (-0700), Mark Sapiro wrote: [...]
If this is the result of a
replyand notreply-allthe client is not behaving reasonably. [...]
I haven't seen it with replies, but rather mail clients recording every address they see into their address book, and then when the user of such a client wants to send new mail to someone they start typing that person's name and their mail client happily auto-completes it with the mailing list's address instead of the intended personal address.
This is one of the reasons we don't use DMARC mitigations for most of our lists, and instead we just try to make Mailman avoid altering anything in the message headers or body that might invalidate DKIM signatures (so no changing From or Reply-To, no adding list-specific subject prefixes, no appending list unsubscribe info to the end of messages...). It's an unfortunate trade-off, but some of our users do tend to get confused by address book pollution.
Jeremy Stanley
Thank you, Mark. Yes, the problem is with the mail clients which harvest addresses inappropriately (I never asked them to). I just found the header filter option, which I has been looking for under ’Settings'. Sorry for taking your time.
It works great!
Yours,
AllanOn Jun 1, 2024, at 09:49, Mark Sapiro <mark@msapiro.net> wrote:
On 5/31/24 22:23, hansen via Mailman-users wrote:
Due to the DMARC mitigation action ‘Replace From: with list address’, it happens often on my lists that someone sends a message to a mangled address, hoping that the message goes to the person listed as the sender. This happens mostly because the mail clients collect previous addresses and use them when as type-ahead candidates for new messages, which may be unrelated to the lists.
DMARC mitigation action ‘Replace From: with list address’ will also place the poster's address in Reply-To: (or Cc: depending on list configuration), so a simple
replyfrom a reasonable MUA should go just to the poster.For example, say the mail client captures my address as “Allan Hansen via <listname>” <listaddress> then later, when the person wants to send a message to me, the type-ahead puts this string in the ’To:’ field: “Allan Hansen via <listname>” and, to make it worse, the actual email address, <listaddress>, is often hidden.
If this is the result of a
replyand notreply-allthe client is not behaving reasonably.The result is that the email gets sent to the list instead of to me, together with (often) personal and (sometimes) embarrassing information.
That is a problem with the client, but I suppose such clients are not uncommon.
Is there a way to reject messages sent to recipients where the name part of the recipient is of the above format, i.e., "Allan Hansen via <listname>"
You could add a header filter on the To header with a regexp like
^.*via <listname>and the desired action.Should I get onto the other list to request this as an enhancement?
I don't think that's necessary in this case, as Header filters should do it.
In general, the best way to request an enhancement is to file an issue with the appropriate GitLab project at
https://gitlab.com/mailman-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to hansen@rc.org
participants (3)
-
hansen -
Jeremy Stanley -
Mark Sapiro