[GH-ISSUE #242] mailer@anonaddy.com ←That address looks like a conventional mailer address & has some bad side effects

kerem commented

2026-03-14 10:33:22 +03:00

Owner

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

When a msg arrives from a mailer, it’s generally to express a technical or delivery problem. Procmail users typically have a stanza like this to ensure such messages go to a folder designated postmaster:

:0 :
* ^FROM_MAILER
postmaster

mailer@anonaddy.com matches that so messages from anyone that are forwarded by anonaddy appear to be originating not from the actual sender but from the mailer itself. So all normal anonyaddy msgs are getting dumped in a postmaster folder. This is my workaround which fixes the problem just from me personally:

:0 :
*  -5^0
*$ -2^0 ${FROM_}.*mailer@anonaddy.com
*  6^0 ^FROM_MAILER
postmaster

Of course the problem with this hack is that what happens if anonaddy’s mailer really does need to send an administrative message to me? It will not make it into postmaster inbox.

Other procmail users are likely to run into this problem.

mailer@anonaddy.com should be replaced with something that doesn't match procmail’s constant regex… the Procmail language is set in stone; it’s been around a long time and has reached full maturity. It will never change.

Originally created by @bruceleerabbit on GitHub (Dec 24, 2021). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/242 When a msg arrives from a mailer, it’s generally to express a technical or delivery problem. Procmail users typically have a stanza like this to ensure such messages go to a folder designated postmaster: ``` :0 : * ^FROM_MAILER postmaster ``` The `FROM_MAILER` object is a Procmail constant that expands to this: `"(^(((Resent-)?(From|Sender)|X-Envelope-From):|>?From )([^>]*[^(.%@a-z0-9])?(Post(ma(st(er)?|n)|office)|(send)?Mail(er)?|daemon|mmdf|n?uucp|ops|r(esponse|oot)|(bbs\.)?smtp(error)?|s(erv(ices?|er)|ystem)|A(dmin(istrator)?|MMGR))(([^).!:a-z0-9][-_a-z0-9]*)?[%@> ][^<)]*($.*$.*)?)?$([^>]|$))"` `mailer@anonaddy.com` matches that so messages from _anyone_ that are forwarded by anonaddy appear to be originating not from the actual sender but from the mailer itself. So all normal anonyaddy msgs are getting dumped in a postmaster folder. This is my workaround which fixes the problem just from me personally: ``` :0 : * -5^0 *$ -2^0 ${FROM_}.*mailer@anonaddy.com * 6^0 ^FROM_MAILER postmaster ``` Of course the problem with this hack is that what happens if anonaddy’s mailer really does need to send an administrative message to me? It will not make it into postmaster inbox. Other procmail users are likely to run into this problem. `mailer@anonaddy.com` should be replaced with something that doesn't match procmail’s constant regex… the Procmail language is set in stone; it’s been around a long time and has reached full maturity. It will never change.

kerem closed this issue

2026-03-14 10:33:27 +03:00

kerem commented

2026-03-14 10:33:33 +03:00

Author

Owner

@willbrowningme commented on GitHub (Jan 31, 2022):

The envelope from address for forwarded message for all aliases is now the actual alias address.

Previously username subdomain aliases e.g. xyz@johndoe.anonaddy.com did have the envelope from address as mailer@anonaddy.com but I recently updated this.

Custom domains that are not verified for sending (don't have the correct DNS records) still come from mailer@anonaddy.me but I do understand your point. What would you suggest instead of mailer?

@willbrowningme commented on GitHub (Jan 31, 2022): The envelope from address for forwarded message for all aliases is now the actual alias address. Previously username subdomain aliases e.g. `xyz@johndoe.anonaddy.com` did have the envelope from address as `mailer@anonaddy.com` but I recently updated this. Custom domains that are not verified for sending (don't have the correct DNS records) still come from `mailer@anonaddy.me` but I do understand your point. What would you suggest instead of `mailer`?

kerem commented

2026-03-14 10:33:38 +03:00

Author

Owner

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

I should first say that I think it's wrong to use the Sender: field. The Sender: field is intended to indicate situations where the msg is originally transmitted by an agent of the author (such as a secretary) acting on the author’s behalf. The RFC states:

The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear.

The forwarding service is not acting as an agent of the author (who doesn't even necessarily know that a forwarding service is in play). The From: field should reflect the author as the author intended, and the Sender: field should be the agent of the author who is transmitting for the author (if this person differs from the author). If Mary transmits a msg for Anna, then (as a recipient) I want to see both the From and Sender fields as they were originally composed.

From there, I'm not 100% certain(1) which field is most appropriate for a forwarding service. I believe the resent- fields should be used, which is documented here:

https://greenbytes.de/tech/webdav/rfc5322.html#resent

And in the context of forwarding, resent- headers is mentioned in section 4.2 of RFC 822.

My intuition is that it should be the Resent-sender: field. RFC 5322 states:

When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be sent.

So perhaps the munged From: field (which I complain about in bug #241) should become the Resent-From: field, and the Resent-Sender: should identify the anonaddy forwarder. Note that if you go in that direction and have Resent-Sender: mailer@anonaddy.me, the problem isn't solved because that still matches the Procmail regular expression.

The question is, why is this even an address? There are various situations where robots send email for which there is no mailbox for replies that is attended. A common approach is to use a bogus address like no-reply@someorg.com. There's a better way. The syntax for the Sender: field (thus also the Resent-Sender: field) allows for it to contain a group. So you can specify a group of size zero and it's RFC-compliant. E.g. Resent-Sender: anonaddy forwarder:;. I draw this from section 1 of RFC 6854.

(1) I have some uncertainty because section 3.6.6 of RFC 5322 describes two methods of email “forwarding”, one of which could match the anonaddy use case, and it says the resent- headers should not be used in that case. But it’s vague enough about the forwarding context to give me uncertainty. From a practical standpoint, it's problematic that anonaddy tampers with Sender: and From: fields & using the Resent- variants would solve the problem.

I searched my own archive of email for resent- headers, and they are very rarely used. The only instances I found were cases where I told my MUA to “bounce” a msg to my home account (which I received at work). That way my home account would receive msgs with original headers in tact (as opposed to a bunch of msgs from myself). This is just what we would want from a forwarding service as well.

@bruceleerabbit commented on GitHub (Feb 3, 2022): I should first say that I think it's wrong to use the `Sender:` field. The `Sender:` field is intended to indicate situations where the msg is originally transmitted by an agent of the author (such as a secretary) acting on the author’s behalf. The [RFC states](https://www.rfc-editor.org/rfc/rfc6854.txt): > The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear. The forwarding service is not acting as an agent of the author (who doesn't even necessarily know that a forwarding service is in play). The `From:` field should reflect the author as the author intended, and the `Sender:` field should be the agent of the author who is transmitting for the author (if this person differs from the author). If Mary transmits a msg for Anna, then (as a recipient) I want to see both the `From` and `Sender` fields as they were originally composed. From there, I'm not 100% certain(1) which field is most appropriate for a forwarding service. I believe the `resent-` fields should be used, which is documented here: https://greenbytes.de/tech/webdav/rfc5322.html#resent And in the context of forwarding, `resent-` headers is mentioned in section 4.2 of [RFC 822](https://www.w3.org/Protocols/rfc822/). My intuition is that it should be the `Resent-sender:` field. RFC 5322 states: > When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be sent. So perhaps the munged `From:` field (which I complain about in bug #241) should become the `Resent-From:` field, and the `Resent-Sender:` should identify the anonaddy forwarder. Note that if you go in that direction and have `Resent-Sender: mailer@anonaddy.me`, the problem isn't solved because that still matches the Procmail regular expression. The question is, why is this even an address? There are various situations where robots send email for which there is no mailbox for replies that is attended. A common approach is to use a bogus address like `no-reply@someorg.com`. There's a better way. The syntax for the `Sender:` field (thus also the `Resent-Sender:` field) allows for it to contain a *group*. So you can specify a group of size zero and it's RFC-compliant. E.g. `Resent-Sender: anonaddy forwarder:;`. I draw this from section 1 of [RFC 6854](https://www.rfc-editor.org/rfc/rfc6854.txt). (1) I have some uncertainty because [section 3.6.6 of RFC 5322](https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.6) describes two methods of email “forwarding”, one of which could match the anonaddy use case, and it says the `resent-` headers should not be used in that case. But it’s vague enough about the forwarding context to give me uncertainty. From a practical standpoint, it's problematic that anonaddy tampers with `Sender:` and `From:` fields & using the `Resent-` variants would solve the problem. I searched my own archive of email for `resent-` headers, and they are very rarely used. The only instances I found were cases where I told my MUA to “bounce” a msg to my home account (which I received at work). That way my home account would receive msgs with original headers in tact (as opposed to a bunch of msgs from myself). This is just what we would want from a forwarding service as well.

kerem commented

2026-03-14 10:33:43 +03:00

Author

Owner

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

FWIW, I looked at other forwarding services.

erine.email: does not touch the Sender: field. In cases where the original msg had a Sender header it was passed through.
anonaddy.me: now it clobbers the Sender: field with a copy of the To: field. This does not make sense to me.
spamgourmet: In 2003, SG clobbered the Sender: with jqh1@spruce.he.net, jqh1@gourmet.spamgourmet.com, or ",,," <jqh1@gourmet.spamgourmet.com>. But in 2004 and thereafter the Sender: field is not tampered with except apparently in the case that a token has been switched to reroute replies through SG (bizarre, because an MUA should not reply to Sender anyway).
33mail: always clobbers Sender: with Sender: 33Mail <sender@mailer1.33mail.com>
simplelogin.eu: does not tamper with Sender:
burnermail.io: does not tamper with Sender:

@bruceleerabbit commented on GitHub (Feb 3, 2022): FWIW, I looked at other forwarding services. * erine.email: does not touch the `Sender:` field. In cases where the original msg had a `Sender` header it was passed through. * anonaddy.me: now it clobbers the `Sender:` field with a copy of the `To:` field. This does not make sense to me. * spamgourmet: In 2003, SG clobbered the `Sender:` with `jqh1@spruce.he.net`, `jqh1@gourmet.spamgourmet.com`, or `",,," <jqh1@gourmet.spamgourmet.com>`. But in 2004 and thereafter the `Sender:` field is not tampered with except apparently in the case that a token has been switched to reroute replies through SG (bizarre, because an MUA should not reply to Sender anyway). * 33mail: always clobbers `Sender:` with `Sender: 33Mail <sender@mailer1.33mail.com>` * simplelogin.eu: does not tamper with `Sender:` * burnermail.io: does not tamper with `Sender:`

kerem commented

2026-03-14 10:33:48 +03:00

Author

Owner

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

I've just pushed an update that passes through the original Sender: header. Please check again now.

@willbrowningme commented on GitHub (Feb 7, 2022): I've just pushed an update that passes through the original `Sender:` header. Please check again now.

kerem commented

2026-03-14 10:33:53 +03:00

Author

Owner

@bruceleerabbit commented on GitHub (Mar 1, 2022):

Is the update supposed to have taken effect on the anonaddy.me service? The last anonaddy msg I received still shows a clobbered Sender: field.

@bruceleerabbit commented on GitHub (Mar 1, 2022): Is the update supposed to have taken effect on the anonaddy.me service? The last anonaddy msg I received still shows a clobbered `Sender:` field.

kerem commented

2026-03-14 10:33:58 +03:00

Author

Owner

@willbrowningme commented on GitHub (Mar 3, 2022):

I've just tested this and it works as expected.

If the original message has the following header: Sender: john@doe.com then this header is passed through untouched in the forwarded message exactly the same as erine.email.

@willbrowningme commented on GitHub (Mar 3, 2022): I've just tested this and it works as expected. If the original message has the following header: `Sender: john@doe.com` then this header is passed through untouched in the forwarded message exactly the same as erine.email.

Rows
Columns

[GH-ISSUE #242] mailer@anonaddy.com ←That address looks like a conventional mailer address & has some bad side effects #778