Score:0

[Postfix]: check_sender_access: How to catch envelope FROM with brackets?

ca flag

Overall goal:

Block specific emails with have "a name" included in their FROM envelope. Example: John <[email protected]>

Current situation:

I have successfully configured the main.cf of Postfix to utilize check_sender_access in smtpd_recipient_restrictions.

I have created my own sender_access file, used postmap on it, so it generates sender_access.db, which is used then by main.cf.

My sender_access file looks like this:

[email protected] REJECT
[email protected] REJECT

This configuration does works as intended and rejects the email when somebody sends an inbound email with "clear" FROM envelope (Example: FROM: [email protected]):

enter image description here

This configuration does not work and reject the email when the sender has set a "name" which appears in the FROM envelope (Example: FROM: John <[email protected]> or FROM: Support <[email protected]>):

enter image description here

The configuration "does not catch" the email address either when the "name" is the same as the email address (some default behavior in some MTA /mail transfer agents/):

enter image description here

What I have tried:

I have tried a sender_access file with the following formatting:

[email protected] REJECT
John <[email protected]> REJECT
"John <[email protected]>" REJECT
John REJECT
<[email protected]> REJECT
"[email protected]" REJECT
john@ REJECT

None of these have practically worked. The only thing which works is if I reject the entire domain:

example.com REJECT

My question:

I have been searching for two days now, tried many articles and finally decided to ask here. Does Postfix support blocking of senders with FROM in the format John <[email protected]>?

Do I need to try some regex (interestingly, I didn't found any - one would think this is something commonsense?).

P.S: Perhaps something which always "catches" the email address inside the brackets in bold:

John <[email protected]>

Thank you!

us flag
Your terminology is confused. You are not actually talking about the ‘envelope from’. The ‘envelope from’ would be the [MAIL FROM command](https://www.rfc-editor.org/rfc/rfc5321#section-4.1.1.2) which does not allow a name at all, *only* a mailbox in angle brackets. The envelope is usually not visible in a web interface.
us flag
Perhaps a more helpful comment, if you are asking about the `From:` header then have a look at the manual page *header_checks*(5) (`man 5 header_checks`), it might just be what you’re looking for. Or ask on the Postfix mailing list.
Placeholder avatar
ca flag
^--- Your suggestions are all wrong. But thanks anyway, E for Effort. :)
Score:0
ca flag

Solution:

I solved this problem by using regular expressions (regexp) checks.


main.cf

smtpd_recipient_restrictions = check_sender_access regexp:/etc/postfix/sender_access

sender_access

# Exact match: [email protected]
/^john@example\.com$/ REJECT

# Advanced match: John <[email protected]>
/john@example\.com/ REJECT

Note: Please be aware if you use only /[email protected]/ without terminating with \ the . character, then it will match all characters in that position except linebreaks (Example: john@example$.com , john@example!.com, etc.)


Testing

You can test your sender_access via with the command:

postmap -q "John <[email protected]" regexp:sender_access

Do not forget to use the following commands in order to make sure your changes take effect:

postmap sender_access
service postfix restart

Additional notes:

1. If you add a new rule within the sender_access file, doing only a postmap sender_access seems to be enough.

2. Sometimes even though the email appears in the frontend to come from John <[email protected] it is actually emailed from an address like <[email protected]>. This is especially through if the sender uses a service such as Amazon SES.

In this case you must block the actual domain (Example in sender_access: /^john@example\.com$/ REJECT). You can see the real address in your Postfix logs:

vim /var/log/mail.log
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.