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 pare
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.
In
>>Depending on whether omain is client or sender or ...
>>
>>...
>>reject_unauth_destination
>>...
>>check_client_access hash:/pathname
>>reject_rbl_client example.com
>>...
>>
>>Or
>>
>> ...
>> 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.
>
>
>Depending on 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 has
>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 firehos
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 s
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
ateful for an assist 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
her 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
reject_rbl_client example.com
...
Or ???
Where the table retur
)
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 outbound.protection.outlook.com, and bypass my RBL
checks. My old understanding is that the first OK "
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 the
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
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 me
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 spe
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 sequence
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
> t
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 dist
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
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/postf
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 I
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
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.
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&#x
ns 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 o
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, and
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.
>
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 th
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 Receive
>> 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 oth
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 ch
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 tagged_
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 does
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 se
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 Plesk ser
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
pr
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
Ok.
Thank you very much, Dominic.
--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
e how
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
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: http://postfix.1071664.n5.nabble.c
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_mail,
>
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
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, thi
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?
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
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
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
> 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 M
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
> 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. Th
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 &
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 confirm
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 ar
> 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 false
p
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.
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.
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
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
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
.
smtpd_xxx_restrictions =
...
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 ^, $,
>
> > 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 r
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 a
e setup 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-chec
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.
Thanks for your feedback.
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
load-b
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 Bart chalkboard Ep. 7G06
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:
/
y approach?
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 accompli
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 2015, at 20:22, Alex wrote:
[...]
smtpd_reci
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 d
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:
> [...]
> smtpd_recipient_restrictions =
> reject_non_fqdn_recipient,
> reject
Hi,
On Mon, Dec 28, 2015 at 12:17 AM, Bill Cole
wrote:
> 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
>> ch
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
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_sender_
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_sender_access map with
domain names 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 t
ccess.
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 would become a free
relay
pass.
t; 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, based on an arbitrarily forgeable se
duplicate 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
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/
/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
. 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_rec
ded the
> sender_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,
>
porary 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
>> : Sender address rejected: Domain not found;
>>
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
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
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_restrictions =
> check_sender_ns_access hash:/etc/postfix/blackli
ient_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:
sm
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 we
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
>>
>> 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 f
_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.
This originated with me trying to have a better understanding of SPF.
check_sender_acc
smtpd_sender_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 o
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 a
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 Wiet
to a holding queue for checking and
> to do 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.post
to do this, I have added 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:
po
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
&
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 complet
Bithead:
> # check_sender_accesshash:/etc/posfix/mywhitelist <-- this killed
If in doubt, look for warning messages in the maillog file.
In this specific case the warnings would have told you that you
the pathname does not exist (you mis-typed it). In addition, you
may have for
1 - 100 of 183 matches
Mail list logo
