starred/anonaddy

Fork 0

mirror of https://github.com/anonaddy/anonaddy.git synced 2026-04-25 14:15:53 +03:00

[GH-ISSUE #241] Munging “From:” headers causes problems. Plz give an opt-out setting for that. #213

New issue

Closed

opened 2026-03-01 17:45:44 +03:00 by kerem · 3 comments

kerem commented

2026-03-01 17:45:44 +03:00

Owner

Originally created by @bruceleerabbit on GitHub (Dec 24, 2021).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/241

A sample /From:/ header looks something like this:

From: "Marge Simpson 'marge at simpsons.org'" <simpsonsfan+marge=simpsons.org@bruceleerabbit.anonaddy.com>

This seems to be trying to overload & repurpose the FROM field instead of using existing standards that already exist for this purpose.

The FROM should not be tampered with. Mail clients and mail processors have expectations that the FROM field will reflect what the sender intended, and rx-side tools rightfully use that field for input for a variety of tasks. The munging is particularly disruptive when an advanced mail system is processing mail from many different standards-conforming sources.

The current FROM header should really be in the REPLY-TO header. Not all users even need this information, but for those who do the REPLY-TO is the proper place. I realize that some mail clients are technologically challenged and may not know how to treat the reply-to field, but when a service serves a wide userbase with many MUAs, the way forward is to assume MUAs are well behaved as opposed to doing a hack to help some bad MUAs at the cost of encumbering proper MUAs. In effect, users who select good software are being crippled.

(The fix)

I suggest a per-user config option like this:

Where would you like the address for anonaddy-routed replies to go?

nowhere (e.g. mutt users can put what they want in the FROM field on outbound msgs and maybe they use an SMTP server that will accomodate; mutt also has some smarts for working out automatically which of the recipients is you and uses that to populate the reply headers)
the Reply-To field
this custom field: (this is useful if a does not want reply-to interaction with every reply, but perhaps in rare corner-case situations they might want to use that address manually)
munge the FROM field

And in the case of option 4 (the current status quo for everyone), I also suggest adding a header like “X-Original-From” or “Original-Sender” which could still provide the unmunged FROM header in full verbatim. Procmail could then look at those supplemental fields to take action.

(Mutt side-effect/impact)

A mutt user would likely have this line in their configs to tell mutt which addresses are held by the user:

alternates [a-zA-Z0-9]+\.?[a-zA-Z0-9]*@bruceleerabbit.anonaddy.com

Since that regexp matches the munged FROM field, the index page in mutt is smart enough to show the TO field instead (because if a msg is /from/ you the /from/ value it's not generally as useful as the /to/ value). In the case of anonaddy, users actually see the less interesting info (the /to/ content) in the page index. The workaround is to do this:

alternates ^[^=]+@bruceleerabbit.anonaddy.(com|me)

Which will work until a user actually puts an “=” in their alias.

As a sidebar, I must say I hate logging into a Microsoft asset to file a bug report. In any case, you guys are doing great work overall and stand above the other forwarding services because of the PGP capability, which is sadly unique to your service.

(Workaround?)

In principle one could create a procmail stanza to unmunge the FROM header, but that could be some quite tricky parsing because the @ sign is replaced with at, and at could have been in the original name portion of the field. The single quotes couldn't be relied on because what if the name portion contained single quotes originally (e.g. “Pete 'Pistol Pete' Rollack”)?

Originally created by @bruceleerabbit on GitHub (Dec 24, 2021). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/241 A sample /From:/ header looks something like this: `From: "Marge Simpson 'marge at simpsons.org'" <simpsonsfan+marge=simpsons.org@bruceleerabbit.anonaddy.com>` This seems to be trying to overload & repurpose the FROM field instead of using existing standards that already exist for this purpose. The FROM should not be tampered with. Mail clients and mail processors have expectations that the FROM field will reflect what the sender intended, and rx-side tools rightfully use that field for input for a variety of tasks. The munging is particularly disruptive when an advanced mail system is processing mail from many different standards-conforming sources. The current FROM header should really be in the REPLY-TO header. Not all users even need this information, but for those who do the REPLY-TO is the proper place. I realize that some mail clients are technologically challenged and may not know how to treat the reply-to field, but when a service serves a wide userbase with many MUAs, the way forward is to assume MUAs are well behaved as opposed to doing a hack to help some bad MUAs at the cost of encumbering proper MUAs. In effect, users who select good software are being crippled. (*The fix*) I suggest a per-user config option like this: Where would you like the address for anonaddy-routed replies to go? 1) nowhere (e.g. mutt users can put what they want in the FROM field on outbound msgs and maybe they use an SMTP server that will accomodate; mutt also has some smarts for working out automatically which of the recipients is you and uses that to populate the reply headers) 2) the Reply-To field 3) this custom field: <enable user to freetype a custom field> (this is useful if a does not want reply-to interaction with every reply, but perhaps in rare corner-case situations they might want to use that address manually) 4) munge the FROM field And in the case of option 4 (the current status quo for everyone), I also suggest adding a header like “X-Original-From” or “Original-Sender” which could still provide the unmunged FROM header in full verbatim. Procmail could then look at those supplemental fields to take action. (*Mutt side-effect/impact*) A mutt user would likely have this line in their configs to tell mutt which addresses are held by the user: `alternates [a-zA-Z0-9]+\.?[a-zA-Z0-9]*@bruceleerabbit.anonaddy.com` Since that regexp matches the munged FROM field, the index page in mutt is smart enough to show the TO field instead (because if a msg is /from/ you the /from/ value it's not generally as useful as the /to/ value). In the case of anonaddy, users actually see the less interesting info (the /to/ content) in the page index. The workaround is to do this: `alternates ^[^=]+@bruceleerabbit.anonaddy.(com|me)` Which will work until a user actually puts an “=” in their alias. As a sidebar, I must say I hate logging into a Microsoft asset to file a bug report. In any case, you guys are doing great work overall and stand above the other forwarding services because of the PGP capability, which is sadly unique to your service. (*Workaround?*) In principle one could create a procmail stanza to unmunge the FROM header, but that could be some quite tricky parsing because the `@` sign is replaced with ` at `, and ` at ` could have been in the original name portion of the field. The single quotes couldn't be relied on because what if the name portion contained single quotes originally (e.g. “Pete 'Pistol Pete' Rollack”)?

kerem closed this issue

2026-03-01 17:45:44 +03:00

kerem commented

2026-03-01 17:45:45 +03:00

Author

Owner

@bruceleerabbit commented on GitHub (Feb 3, 2022):

Well, tampering with the Reply-To: field is kind of a sketchy idea (though not nearly as bad as tampering with the FROM field as it is now).

The best approach as far as I can tell is to put the currently munged From: contents in a new field labeled Resent-From: (see bug #242). But note this is not perfect either because mail clients are not supposed to process or react to the Resent- headers in any way, and probably many MUAs don't even show those fields to the user unless they specifically ask for a raw view of the headers.

So there's merit to hijacking the Reply-To field and there's also merit to using Resent-From, generally depending on the MUA, user expertise, and the user’s workflow.

In the end I’m afraid this really should be a user-specified configuration option.

Another consideration: when anonaddy creates a reply forwarding address, does it store the FROM address or the REPLY-TO? Ideally it should route to the Reply-To address if it exists, and otherwise route to the From address. And the headers should enable the recipient to know what's going on. That is, create an X-Original-Reply-To if Reply-To is being munged, and create X-Original-From if From is being munged.

@bruceleerabbit commented on GitHub (Feb 3, 2022): Well, tampering with the `Reply-To:` field is kind of a sketchy idea (though not nearly as bad as tampering with the FROM field as it is now). The best approach as far as I can tell is to put the currently munged `From:` contents in a new field labeled `Resent-From:` (see bug #242). But note this is not perfect either because mail clients are not supposed to process or react to the `Resent-` headers in any way, and probably many MUAs don't even show those fields to the user unless they specifically ask for a raw view of the headers. So there's merit to hijacking the `Reply-To` field and there's also merit to using `Resent-From`, generally depending on the MUA, user expertise, and the user’s workflow. In the end I’m afraid this really should be a user-specified configuration option. Another consideration: when anonaddy creates a reply forwarding address, does it store the FROM address or the REPLY-TO? Ideally it should route to the `Reply-To` address if it exists, and otherwise route to the `From` address. And the headers should enable the recipient to know what's going on. That is, create an `X-Original-Reply-To` if `Reply-To` is being munged, and create `X-Original-From` if `From` is being munged.

kerem commented

2026-03-01 17:45:45 +03:00

Author

Owner

@willbrowningme commented on GitHub (Feb 7, 2022):

I've added the following headers on forwarded messages:

X-AnonAddy-Original-From-Header
X-AnonAddy-Original-Reply-To-Header

@willbrowningme commented on GitHub (Feb 7, 2022): I've added the following headers on forwarded messages: - `X-AnonAddy-Original-From-Header` - `X-AnonAddy-Original-Reply-To-Header`

kerem commented

2026-03-01 17:45:45 +03:00

Author

Owner

@willbrowningme commented on GitHub (Nov 1, 2022):

The reason the From: header is munged and shown in that way is because if it is left untouched e.g.

From: "PayPal 'support@paypal.com'" paypal+support=paypal.com@bruceleerabbit.anonaddy.com

Then it is highly likely to be rejected as a suspected phishing attempt.

You can already change the setting on the settings page "Use Reply-To Header For Replying" which will set that address as the Reply-To: header instead.

I will be adding the option to change the format of the From: header shortly - https://github.com/anonaddy/anonaddy/discussions/370

@willbrowningme commented on GitHub (Nov 1, 2022): The reason the `From:` header is munged and shown in that way is because if it is left untouched e.g. From: "PayPal 'support@paypal.com'" <paypal+support=paypal.com@bruceleerabbit.anonaddy.com> Then it is highly likely to be rejected as a suspected phishing attempt. You can already change the setting on the settings page "Use Reply-To Header For Replying" which will set that address as the `Reply-To:` header instead. I will be adding the option to change the format of the `From:` header shortly - https://github.com/anonaddy/anonaddy/discussions/370

kerem referenced this issue

2026-03-14 10:30:08 +03:00

[GH-ISSUE #213] Error 500 on User Login #757

No labels

bug

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/anonaddy#213

No description provided.

Rows
Columns