[pfx] Re: postfix check_sender_access and subdomain test

On 28.02.24 21:31, Scott Techlist via Postfix-users wrote: As I understand from your explanation, if I keep my parent_domain_matches_subdomains = smtpd_access_maps Then the preceding dot format is moot/not needed. Only outbound.protection.outlook.com OK I recommend keeping

[pfx] Re: postfix check_sender_access and subdomain test

Noel: As I understand from your explanation, if I keep my parent_domain_matches_subdomains = smtpd_access_maps Then the preceding dot format is moot/not needed. Only outbound.protection.outlook.com OK Check. >The reason it doesn't work is you're confusing sender and client.

[pfx] Re: postfix check_sender_access and subdomain test

>>Depending on whether omain is client or sender or ... >> >>... >>reject_unauth_destination >>... >>check_client_access hash:/pathname >>reject_rbl_client example.com >>... >> >>Or >> >> ...

[pfx] Re: postfix check_sender_access and subdomain test

>> check_sender_access hash:/etc/postfix/sender_checks, > >That directive checks the email address which is used in the SMTP MAIL >FROM command. > >I believe you need to use check_client_access to check the verified >client hostname instead of check_sender_access. > >

[pfx] Re: postfix check_sender_access and subdomain test

whether omain is client or sender or ... > >... >reject_unauth_destination >... >check_client_access hash:/pathname >reject_rbl_client example.com >... > >Or > >... >reject_unauth_destination >... >check_sender_access hash:/pathname >

[pfx] Re: postfix check_sender_access and subdomain test

>I can tell you there is significant spam from that Microsoft IP space. That >spamcop doesn't have false positives, but rather due to >the sharing of IP >space, senders that aren't spammers get tarred with the same brush as the >spammers. I did a grep on the maillog >files and that is a

[pfx] postfix check_sender_access and subdomain test

I can tell you there is significant spam from that Microsoft IP space. That spamcop doesn't have false positives, but rather due to the sharing of IP space, senders that aren't spammers get tarred with the same brush as the spammers.  I did a grep on the maillog files and that is a firehose of

[pfx] Re: postfix check_sender_access and subdomain test

2.2.10. (I know, working on migrating) access maps processing has not changed significantly since then. main.cf: (full postconf –n output follows below) parent_domain_matches_subdomains = smtpd_access_maps check_sender_access hash:/etc/postfix/sender_checks, I need to let mail from

[pfx] Re: postfix check_sender_access and subdomain test

to remedy. This box is an old postfix install Postfix version 2.2.10. (I know, working on migrating) main.cf: (full postconf -n output follows below) parent_domain_matches_subdomains = smtpd_access_maps check_sender_access hash:/etc/postfix/sender_checks, That directive checks

[pfx] Re: postfix check_sender_access and subdomain test

nt or sender or ... ... reject_unauth_destination ... check_client_access hash:/pathname reject_rbl_client example.com ... Or ... reject_unauth_destination ... check_sender_access hash:/pathname reject_rbl_client example.com ... Or ??? Where the table returns OK for the allowl

[pfx] postfix check_sender_access and subdomain test

postconf -n output follows below) parent_domain_matches_subdomains = smtpd_access_maps check_sender_access hash:/etc/postfix/sender_checks, I need to let mail from outbound.protection.outlook.com, and bypass my RBL checks. My old understanding is that the first OK "wins" (maybe no

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

Having 12x that text in the postconf masnpage would not help. Certainly not, but I think there's a good middle ground. A more practical change would just make brief reference to the distinction. For example: check_recipient_access type:table Search the specified access(5) database for

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

Jakob Cornell via Postfix-users: > Hi Wietse, > > > I can add a debug log that a specific table is skipped for a specific name. > > Ah yes, that's a better fix. That would take care of my confusion with the > logging. > > Do you have any thoughts on postconf(5) describing partial key > lookups

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

Hi Wietse, I can add a debug log that a specific table is skipped for a specific name. Ah yes, that's a better fix. That would take care of my confusion with the logging. Do you have any thoughts on postconf(5) describing partial key lookups in the descriptions for check_*_access without

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

Jakob Cornell via Postfix-users: > If I understand right the non-indexed skip is implemented by the > 'continue' at global/maps.c:199, so a flag could be added to track > whether execution has passed line 199 and if not, the log statement > at 221 could be skipped. I can add a debug log that a

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

The logging code lives outside the individual table drivers and with "_maps" parameters that support multiple tables, above any individual table lookup. Oh I see. Well without rearchitecting the logging it seems this could be made more intuitive for the case where all of the maps in a

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

On Mon, Feb 12, 2024 at 09:05:12PM -0600, Jakob Cornell via Postfix-users wrote: > Can we improve this so it's easier to get this right on the first try > as a newcomer, and make it more clear what's happening at run time? It > looks like a code change to skip the logging along with the actual >

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

Thanks Viktor. I found what I believe you're referencing in the access(5) man page: With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, patterns are tried in the order as listed below: Is this the only documentation explaining this

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

On Sun, Feb 11, 2024 at 07:42:24PM -0600, Jakob Cornell via Postfix-users wrote: > smtpd_recipient_restrictions = > check_sender_access regexp:/etc/postfix/db/sender_access_table > ... As documented regexp, pcre, ... tables don't do "partial key" lookups.

[pfx] Unexpected behavior of regexp table in check_sender_access directive

Hi folks, I'm updating the configuration of my mail server and having problems with a regexp table. This is the relevant configuration in main.cf: smtpd_recipient_restrictions = check_sender_access regexp:/etc/postfix/db/sender_access_table ... And /etc/postfix/db

[pfx] Re: Problems with check_sender_access and bypassing Amavis

On Wed, Sep 20, 2023 at 10:33:38PM +0200, Benny Pedersen via Postfix-users wrote: > its just a fail to accept local sender enveloppes on port 25, did you ensure > this is not possible ? > > logs is equal sender and recipient spams > > if its only on non port 25 its ok Hi Benny, I'm sorry but

[pfx] Re: Problems with check_sender_access and bypassing Amavis

Bryan K. Walton via Postfix-users skrev den 2023-09-20 22:22: On Wed, Sep 20, 2023 at 03:01:21PM -0500, Noel Jones via Postfix-users wrote: The check_sender_access must be BEFORE any permit_mynetworks or permit_sasl_authenticated. Thanks Noel! That was the issue. I had check_sender_access

[pfx] Re: Problems with check_sender_access and bypassing Amavis

On Wed, Sep 20, 2023 at 03:01:21PM -0500, Noel Jones via Postfix-users wrote: > The check_sender_access must be BEFORE any permit_mynetworks or > permit_sasl_authenticated. Thanks Noel! That was the issue. I had check_sender_access AFTER permit_mynetworks and permit_sasl_authenticated.

[pfx] Re: Problems with check_sender_access and bypassing Amavis

from Amavis scanning. To do that, I've added to our smtpd_sender_restrictions in main.cf: check_sender_access hash:/etc/postfix/specific_sender_rules The /etc/postfix/specific_sender_rules file contains: example.com FILTER smtp:[127.0.0.1]:10025 I've found that this doesn't work. Mail

[pfx] Problems with check_sender_access and bypassing Amavis

in main.cf: check_sender_access hash:/etc/postfix/specific_sender_rules The /etc/postfix/specific_sender_rules file contains: example.com FILTER smtp:[127.0.0.1]:10025 I've found that this doesn't work. Mail that hits the server from this sending domain still gets handed off to Amavis

Re: Assist with a spam message, check_sender_access and check_client_access targets

Wietse Venema: > Viktor Dukhovni: > > On Sat, Jan 21, 2023 at 02:49:34PM -0500, Wietse Venema wrote: > > > > > Correction: the MTA<==>Milter protocol hides the Received: header > > > that is prepended by the MTA, but it exposes headers that are already > > > present. That's what Sendmail does,

Re: Assist with a spam message, check_sender_access and check_client_access targets

Viktor Dukhovni: > On Sat, Jan 21, 2023 at 02:49:34PM -0500, Wietse Venema wrote: > > > Correction: the MTA<==>Milter protocol hides the Received: header > > that is prepended by the MTA, but it exposes headers that are already > > present. That's what Sendmail does, and therefore Postfix, too. >

Re: Assist with a spam message, check_sender_access and check_client_access targets

On Sat, Jan 21, 2023 at 02:49:34PM -0500, Wietse Venema wrote: > Correction: the MTA<==>Milter protocol hides the Received: header > that is prepended by the MTA, but it exposes headers that are already > present. That's what Sendmail does, and therefore Postfix, too. Not only does Sendmail do

Re: Assist with a spam message, check_sender_access and check_client_access targets

Bill Cole: > What is likely happening here is that when a milter sees a message, it > does not have the current Received header, because it has yet to be > fully received. If you are extracting this message from that stage > rather than after final delivery, Postfix has not yet added the

RE: Assist with a spam message, check_sender_access and check_client_access targets

>> No idea what's stripping them. I use amavisd and spamassassin, the >> later I expect. > >Nope. ASF SpamAssassin does not manipulate existing headers in any way >except for pre-existing X-Spam-* headers that it is specifically >configured to remove. When used via amavisd or MIMEDefang or any

Re: Assist with a spam message, check_sender_access and check_client_access targets

On 2023-01-20 at 17:39:29 UTC-0500 (Fri, 20 Jan 2023 16:39:29 -0600) Scott Techlist is rumored to have said: Noel: [...] I don't see any Received: headers. Something in your system removed those. The Received: headers will include the client IP and possibly hostname that could be used in a

Re: Assist with a spam message, check_sender_access and check_client_access targets

Dnia 20.01.2023 o godz. 15:25:56 Scott Techlist pisze: > X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on > myhost.myservername.com > X-Virus-Scanned: amavisd-new at myservername.com > X-Spam-Flag: NO > X-Spam-Score: 1.451 > X-Spam-Level: * > X-Spam-Status: No, score=1.451

RE: Assist with a spam message, check_sender_access and check_client_access targets

Re: Raf >In other words, check_sender_access tests the address >that ended up being stored in the From_ mbox pseudo header: > > From > bounce-91040_html-994996332-142678-514026815-45...@bounce.s11.mc.pd25.com > Fri Jan 20 12:40:11 2023 > >And check_client_access d

Re: Assist with a spam message, check_sender_access and check_client_access targets

On Fri, Jan 20, 2023 at 03:53:25PM -0600, Noel Jones wrote: > On 1/20/2023 3:25 PM, Scott Techlist wrote: > > I'm fuzzy on if I can block a message like the one below one using > > check_sender_access or check_client_access. > > check_sender_access is the envelope sender

Re: check_sender_access not working on local senders

Yep, working perfectly, thanks! From: Bill Cole To: Postfix users Sent: 09.02.2020 2:12 AM Subject: Re: check_sender_access not working on local senders On 8 Feb 2020, at 17:25, simonh wrote: > Hello, > > I am trying to automate anti-spam flood on our Ples

Re: check_sender_access not working on local senders

On 8 Feb 2020, at 17:25, simonh wrote: Hello, I am trying to automate anti-spam flood on our Plesk servers, and my goal is to be able to REJECT mails from abused mailboxes or from non-captcha'd web forms. On the mailboxes, the directive check_sender_access works as expected, no problem

check_sender_access not working on local senders

Hello, I am trying to automate anti-spam flood on our Plesk servers, and my goal is to be able to REJECT mails from abused mailboxes or from non-captcha'd web forms. On the mailboxes, the directive check_sender_access works as expected, no problem here. Whenever I try to REJECT mails from root

Re: What does check_sender_access checks?

Ok. Thank you very much, Dominic. -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: What does check_sender_access checks?

could I allow all mail from a specific "Mail From:" to be relayed? Is it possible? no. the "mail from:" is not a header, but an envelope from address, so you must use check_sender_access instead. However, you should not allow relaying based on envelope from address. Maybe on

Re: What does check_sender_access checks?

Ok. In this case the Return-Path is kinda random, so there's no use to it. On the other hand, looking to the headers_checks examples I cannot see how could I allow all mail from a specific "Mail From:" to be relayed? Is it possible? Thank you. -- Sent from:

Re: What does check_sender_access checks?

gt;reject_invalid_hostname, >reject_non_fqdn_hostname, >reject_non_fqdn_sender, >reject_unknown_sender_domain, >reject_unknown_recipient_domain, >check_sender_access hash:/etc/postfix/senders, >check_recipient_access hash:/etc/postfix/users_internet_ma

What does check_sender_access checks?

ent_domain, check_sender_access hash:/etc/postfix/senders, check_recipient_access hash:/etc/postfix/users_internet_mail, reject And this is on the "real" message: . . . From: To: . . . Return-Path: f9895e47.ANEAAF6zi2UAAKnhCGkAASpLLm4AAA0fMwBeHFnT@another.domain

Re: Multiple tables for check_sender_access

smtpd_sender_restrictions = reject_non_fqdn_sender check_sasl_access hash:/etc/postfix/sasl_access check_sasl_access hash:/etc/postfix/sasl_access_2 reject_sender_login_mismatch That should work just fine. What errors did you get? Sorry, i probably did something wrong while testing,

Re: Multiple tables for check_sender_access

On 11 Jan 2020, at 02:25, azu...@pobox.sk wrote: > smtpd_sender_restrictions = > reject_non_fqdn_sender > check_sasl_access hash:/etc/postfix/sasl_access > check_sasl_access hash:/etc/postfix/sasl_access_2 > reject_sender_login_mismatch That should work just fine. What errors did you get?

Re: Multiple tables for check_sender_access

On Sat, Jan 11, 2020 at 10:25:42AM +0100, azu...@pobox.sk wrote: > is it possible to specify multiple tables for check_sender_access used > in smtpd_sender_restrictions? Few examples i tried (none worked): > > smtpd_sender_restrictions = >reject_non_fqdn_sender >chec

Re: Multiple tables for check_sender_access

azu...@pobox.sk: > Hi, > > is it possible to specify multiple tables for check_sender_access used > in smtpd_sender_restrictions? Few examples i tried (none worked): > > smtpd_sender_restrictions = >reject_non_fqdn_sender >check_sasl_access hash:/etc/postfix/s

Multiple tables for check_sender_access

Hi, is it possible to specify multiple tables for check_sender_access used in smtpd_sender_restrictions? Few examples i tried (none worked): smtpd_sender_restrictions = reject_non_fqdn_sender check_sasl_access hash:/etc/postfix/sasl_access hash:/etc/postfix/sasl_access_2

Re: empty MAIL FROM and check_sender_access

> On Sep 25, 2018, at 12:27 PM, Stefan Bauer wrote: > > I notice that only outlook out of all my mail clients, use the null mailer > address. it looks to me after reading the standard - that outlook does it > right. Is that correct? Outlook is perhaps the only one that is actually sending

Re: empty MAIL FROM and check_sender_access

I notice that only outlook out of all my mail clients, use the null mailer address. it looks to me after reading the standard - that outlook does it right. Is that correct? Am Di., 25. Sep. 2018 um 17:22 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 25, 2018, at 10:13

Re: empty MAIL FROM and check_sender_access

> On Sep 25, 2018, at 10:13 AM, Stefan Bauer wrote: > > I was more asking if it's even a good idea to add the null entry to the > table? i would like to be a good postmaster but not want to relax policies > for allowed sender addresses. You need to allow mail with null return addresses.

empty MAIL FROM and check_sender_access

t; Hi, > > > > I'm using smtpd_sender_restrictions = check_sender_access > > hash:/etc/postfix/allowed_sender > > > > to make sure, my senders only send out with pre-defined and allowed domains. > > > > Now i noticed, that if my users acknowledge "read

Re: empty MAIL FROM and check_sender_access

Stefan Bauer: > Hi, > > I'm using smtpd_sender_restrictions = check_sender_access > hash:/etc/postfix/allowed_sender > > to make sure, my senders only send out with pre-defined and allowed domains. > > Now i noticed, that if my users acknowledge "read confi

empty MAIL FROM and check_sender_access

Hi, I'm using smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/allowed_sender to make sure, my senders only send out with pre-defined and allowed domains. Now i noticed, that if my users acknowledge "read confirmations" in clients, mails in the following form arrive

Re: Blocking TLDs with check_sender_access

> On Jun 26, 2018, at 1:15 PM, @lbutlr wrote: > >> No, it works substantially better in check_sender_access, and very poorly >> in header_checks. > > It works very well for me, and has for years. The regular expressions you posted are fragile, subject to easy fal

Re: Blocking TLDs with check_sender_access

On Jun 26, 2018, at 09:10, Viktor Dukhovni wrote: > No, it works substantially better in check_sender_access, and very poorly > in header_checks. It works very well for me, and has for years. -- This is my signature. There are many like it, but this one is mine.

Re: Blocking TLDs with check_sender_access

50 Mail to or from this TLD is not allowed > > But this should basically work much the same in check_sender_access No, it works substantially better in check_sender_access, and very poorly in header_checks. DO NOT use header checks for sender address blacklists. -- Viktor.

Re: Blocking TLDs with check_sender_access

On 25 Jun 2018, at 14:45, Alex wrote: > I have a check_sender_access restriction that blocks many TLDs like > .red and .space. Problem is that we have one legitimate .red customer > (what was he thinking?) that needs to send us mail. How can I allow > this single domain? I use h

Re: Blocking TLDs with check_sender_access

Alex: > HI, > > I have a check_sender_access restriction that blocks many TLDs like > .red and .space. Problem is that we have one legitimate .red customer > (what was he thinking?) that needs to send us mail. How can I allow > this single domain? > > s

Blocking TLDs with check_sender_access

HI, I have a check_sender_access restriction that blocks many TLDs like .red and .space. Problem is that we have one legitimate .red customer (what was he thinking?) that needs to send us mail. How can I allow this single domain? smtpd_sender_restrictions = permit_mynetworks

Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

strictions = ... check_sender_access pcre:/etc/postfix/sender-access.pcre ... /etc/postfix/sender-access.pcre: # First, a rule that matches health-check mail. /^smtp-health-checks@example\.com$/ DUNNO # Add a BCC recipient to other email. . BCC f...@example.com The ^, $, \, and . are sp

Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

> > > For the last entry that BCC's "everything else", is the * character a > > valid source? > > The access map syntax is documented. http://www.postfix.org/access.5.html > There is no '*' in there. If you must filter on sender address, you can use a regexp: or pcre:

Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

deoren: > /etc/postfix/sender-access.cf: ># First, a rule that matches health-check mail. >smtp-health-che...@example.com DUNNO ># Add a BCC recipient to other email. >* BCC f...@example.com > > For the last entry that BCC's "everything else", is the * character

Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

to use the proposed solution, but stopped part way through. I see that we're matching on the client IP here with an action of DUNNO. Instead of matching on the IP with check_client_access, could we match on the sender address instead with check_sender_access so that non-health-check mail from

Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

On 5/12/2018 1:51 AM, @lbutlr wrote: On 11 May 2018, at 09:55, deoren wrote: BCC everything EXCEPT for health check emails generated by our HAProxy load-balancer Seems it would be much simpler to BCC everything and then discard the few messages you don’t want.

Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

On 5/11/2018 2:20 PM, Wietse Venema wrote: deoren: My apologies if I overlooked an answer somewhere, but I checked the docs and performed a brief search of the archives before asking and didn't spot the answer. Goal: BCC everything EXCEPT for health check emails generated by our HAProxy

Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

On 11 May 2018, at 09:55, deoren wrote: > BCC everything EXCEPT for health check emails generated by our HAProxy > load-balancer Seems it would be much simpler to BCC everything and then discard the few messages you don’t want. -- I WILL NOT INSTIGATE REVOLUTION

Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

deoren: > My apologies if I overlooked an answer somewhere, but I checked the docs > and performed a brief search of the archives before asking and didn't > spot the answer. > > Goal: > > BCC everything EXCEPT for health check emails generated by our HAProxy > load-balancer Use a CIDR map:

Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

? always_bcc = bcc-...@example.com smtpd_delay_reject = yes smtpd_recipient_restrictions = ... check_sender_access proxy:mysql:/etc/postfix/mysql-sender_access.cf, ... Within the access table I'm mapping the health check sender address to the DISCARD action. This appears to accomplish the original

Re: check_sender_access and pattern matching

On 12/30/2015 7:45 PM, Alex wrote: > > The docs say reject_unlisted_recipient rejects mail when the recipient > is not listed in the list of valid recipients for its domain class. I > assume this means an IP listed in mynetworks or an entry from the > check_recipient_access list? > > The part I

Re: check_sender_access and pattern matching

Hi, I hoped I could ask another question. Below is my smtpd_recipient_restrictions as we were discussing earlier this week: On Sun, Dec 27, 2015 at 9:37 PM, Bill Cole wrote: > On 27 Dec 2015, at 20:22, Alex wrote: > [...] >

Re: check_sender_access and pattern matching

On 30 Dec 2015, at 20:45, Alex wrote: Hi, I hoped I could ask another question. Well, you can ask... Below is my smtpd_recipient_restrictions as we were discussing earlier this week: On Sun, Dec 27, 2015 at 9:37 PM, Bill Cole wrote: On 27 Dec

Re: check_sender_access and pattern matching

mynetworks or duplicate the >> check_sender_access map in smtpd_recipient_restrictions to avoid being >> rejected in the RBLs there, correct? > > If you are not willing to put the IPs in mynetworks, I would still urge you > to NOT use check_sender_access to whitelist sources that you can i

Re: check_sender_access and pattern matching

One of the reasons I separated >> the restrictions was to avoid the problem of too permissive access. > > > I can see why: if your check_sender_access whitelist is in > smtpd_recipient_restrictions, it whitelists against every rule following it > in smtpd_recipient_restrictions

Re: check_sender_access and pattern matching

avoid the problem of too permissive access. I can see why: if your check_sender_access whitelist is in smtpd_recipient_restrictions, it whitelists against every rule following it in smtpd_recipient_restrictions, based on an arbitrarily forgeable sender domain. Using a magically bogus sender domain

Re: check_sender_access and pattern matching

On 27 Dec 2015, at 22:48, Alex wrote: Hopefully the smtpd_sender_restrictions I posted above is correct, but I will also have to either add the IPs to mynetworks or duplicate the check_sender_access map in smtpd_recipient_restrictions to avoid being rejected in the RBLs there, correct? If you

Re: check_sender_access and pattern matching

ur problem, there is mail which you must accept that uses a sender domain name which does not resolve. However, you generally want to use reject_unknown_sender_domain, which is a good thing. The ideal way to address that problem is a check_sender_access map with your exception in th

Re: check_sender_access and pattern matching

and IPs that I need to ensure are not >> rejected. Given the restrictions below, if I add the IPs to a >> check_client_access map in smtpd_client_restrictions, and the >> hosts/domains to a check_sender_access map in >> smtpd_sender_restrictions, can I expect them to bypass any further

Re: check_sender_access and pattern matching

Hi, > As I understand your problem, there is mail which you must accept that uses > a sender domain name which does not resolve. However, you generally want to > use reject_unknown_sender_domain, which is a good thing. > > The ideal way to address that problem is a check_se

Re: check_sender_access and pattern matching

hash:/etc/postfix/helo_checks, >> reject_non_fqdn_helo_hostname, >> reject_invalid_helo_hostname, >> check_policy_service inet:127.0.0.1:2501, >> check_recipient_access pcre:/etc/postfix/relay_recips_access, >> permit >> >> smtpd_sender_restrictions = permit_m

Re: check_sender_access and pattern matching

/helo_checks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, check_policy_service inet:127.0.0.1:2501, check_recipient_access pcre:/etc/postfix/relay_recips_access, permit smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/sender_checks

Re: check_sender_access and pattern matching

rejection rules then you don't need to duplicate map rules to exempt special cases from them. One of the reasons I separated the restrictions was to avoid the problem of too permissive access. I can see why: if your check_sender_access whitelist is in smtpd_recipient_restrictions, it whitelists

Re: check_sender_access and pattern matching

e. I actually had that in the file already, and >> it just stopped working about a week ago. I just added the >> sender_access file to smtpd_recipient_access and now it's working: >> >> smtpd_recipient_restrictions = >> reject_non_fqdn_recipient, >&g

Re: check_sender_access and pattern matching

nder_access file to smtpd_recipient_access and now it's working: > > smtpd_recipient_restrictions = > reject_non_fqdn_recipient, > check_sender_access hash:/etc/postfix/sender_checks, > reject_non_fqdn_sender, > reject_unlisted_recipient, > reject_unknow

Re: check_sender_access and pattern matching

>> hostname. The temporary solution is to add a check_sender_access >> entry, but I must be doing something wrong. >> >> Dec 21 12:30:16 mail02 postfix/smtpd[1560]: NOQUEUE: reject: RCPT from >> mailout.example.com[64.123.123.200]: 450 4.1.8 >> <u...@invalid.e

Re: check_sender_access and pattern matching

On 12/21/2015 11:38 AM, Alex wrote: > Hi, > I have a postfix-2.10 fedora22 system and having trouble with my > sender checks. I have a domain that is sending mail with an invalid > hostname. The temporary solution is to add a check_sender_access > entry, but I must be doing

check_sender_access and pattern matching

Hi, I have a postfix-2.10 fedora22 system and having trouble with my sender checks. I have a domain that is sending mail with an invalid hostname. The temporary solution is to add a check_sender_access entry, but I must be doing something wrong. Dec 21 12:30:16 mail02 postfix/smtpd[1560]: NOQUEUE

Re: check_sender_access and spoofing

nt_access that permits all the authorized IPs. > > Make sure to do this in smtpd_sender_restrictions so that settings > here don't affect relay rules. So where I previously had permit_mynetworks and a check_sender_access check for my domain in smtpd_sender_restrictions, I should do something like: smtpd_sender_rest

Re: check_sender_access and spoofing

t relay rules. > > So where I previously had permit_mynetworks and a check_sender_access > check for my domain in smtpd_sender_restrictions, I should do > something like: > > smtpd_sender_restrictions = > check_sender_ns_access hash:/etc/postfix/blacklist_ns

Re: check_sender_access and spoofing

Hi, >> This originated with me trying to have a better understanding of SPF. >> check_sender_access consults $mynetworks to determine which servers >> can send mail as my domain. > > Eh? check_sender_access can only check the envelope sender address, > not a network o

Re: check_sender_access and spoofing

On 12/10/2015 8:39 AM, Alex wrote: >> >> This is independent of SPF. The rules discussed blocks your domain >> as envelope sender except for a whitelist you have specified >> (permit_mynetworks). > > Yes, and that was part of my concern. There are includes in our SPF > record for networks that

check_sender_access and spoofing

Hi, I'm trying to configure postfix-3.0.2 to reject mail trying to spoof my domain in the envelope FROM address without rejecting my own domain, and I'm doing something wrong. I've set up check_sender_access to INFO on the entries until I can get this figured out, but here is an example

Re: check_sender_access and spoofing

er_restrictions = permit_mynetworks check_sender_access hash:/path/to/reject_my_domain > > I've set up check_sender_access to INFO on the entries until I can get > this figured out, but here is an example of it logging an attempt to > otherwise block an email from one of our outbound mail se

Re: check_sender_access and spoofing

ons = > permit_mynetworks > check_sender_access hash:/path/to/reject_my_domain The combination of your suggestions, and probably most specifically the permit_mynetworks, is what appears to have fixed it. This originated with me trying to have a better understanding of SPF. check_sender_access consul

Re: check_sender_access and spoofing

gt;> Typically this is done something like: >> smtpd_sender_restrictions = >> permit_mynetworks >> check_sender_access hash:/path/to/reject_my_domain > > The combination of your suggestions, and probably most specifically > the permit_mynetworks, is what appears to have fixed it. &

Re: check_sender_access has no effect (for me)

this, I have added in to /etc/postfix/main.cf: check_sender_access = hash:/etc/zpanel/configs/postfix/hold check_sender_access is not a configuration parameter. http://www.postfix.org/postconf.5.html#check_sender_access http://www.postfix.org/postconf.5.html#smtpd_sender_restrictions Wietse

Re: check_sender_access has no effect (for me)

On Friday, 28 August, 2015 06:24 PM, Wietse Venema [via Postfix] wrote: check_sender_access is not a configuration parameter. http://www.postfix.org/postconf.5.html#check_sender_access http://www.postfix.org/postconf.5.html#smtpd_sender_restrictions Wietse Hi Wietse, Thanks for your

check_sender_access has no effect (for me)

in to /etc/postfix/main.cf: check_sender_access = hash:/etc/zpanel/configs/postfix/hold The contents of /etc/zpanel/configs/postfix/hold are: m...@myemail.com HOLD (m...@example.com is a replacement for my real email which I don't want to post). I then ran: postmap hash:/etc/zpanel/configs

RE: check_sender_access stops incoming mail

Wietse, # check_sender_accesshash:/etc/posfix/mywhitelist -- this killed the pathname does not exist (you mis-typed it). In addition, you Ok, that's embarrassing. Thanks for catching it, though. But even so, why would pointing to a non-existent file completely halt incoming mail

Re: check_sender_access stops incoming mail

Bithead: Wietse, # check_sender_accesshash:/etc/posfix/mywhitelist -- this killed the pathname does not exist (you mis-typed it). In addition, you Ok, that's embarrassing. Thanks for catching it, though. But even so, why would pointing to a non-existent file completely halt

check_sender_access stops incoming mail

. There are some clients who send from multiple IP addresses, and rather than managing their IP address access, it would be simpler to whitelist their email addresses. I tried adding check_sender_access, with a table containing only 2 addresses, e.g.: User1@domain1 OK User2@domain2 OK

  1   2   >