Am 17.07.25 um 13:08 schrieb Marko Cupać via Postfix-users:
There are some "valid" senders which seem to violate their own policies
What is the most appropriate way to selectively accept those emails?
configure OpenDMARC (!) to not reject this messages:
-
https://manpages.debian.org/bookw
On 17.07.25 13:08, Marko Cupać via Postfix-users wrote:
I have postfix setup with opendmarc and opendkim:
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:8891,inet:127.0.0.1:8893
non_smtpd_milters = $smtpd_milters
This works as intended (rejecting mails which violate dmarc policie
Marko Cupać via Postfix-users skrev den 2025-07-17 13:08:
Hi,
I have postfix setup with opendmarc and opendkim:
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:8891,inet:127.0.0.1:8893
non_smtpd_milters = $smtpd_milters
This works as intended (rejecting mails which violate dmarc
Hi,
I have postfix setup with opendmarc and opendkim:
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:8891,inet:127.0.0.1:8893
non_smtpd_milters = $smtpd_milters
This works as intended (rejecting mails which violate dmarc policies).
There are some "valid" senders which seem to vio
On 2025-01-27 at 08:20:19 UTC-0500 (Mon, 27 Jan 2025 14:20:19 +0100)
Marko Cupać via Postfix-users
is rumored to have said:
[...]
... Microsoft's servers are frequently being (temporarily) blocked by
spamcop:
For good cause...
Jan 27 10:47:20 mx1 postfix/smtpd[67827]: NOQUEUE: reject: RCPT
On 27.01.25 14:20, Marko Cupać via Postfix-users wrote:
with my current configuration (relevant part):
smtpd_client_restrictions =
check_client_access hash:$config_directory/client_access
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_relay_restrictions =
re
Hi,
with my current configuration (relevant part):
smtpd_client_restrictions =
check_client_access hash:$config_directory/client_access
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_relay_restrictions =
reject_non_fqdn_recipient
reject_non_fqdn_sender
On 31.05.24 12:19, Gerben Wierda via Postfix-users wrote:
smtpd_milters =
unix:/opt/local/var/spool/postfix/opt/local/var/run/rspamd/milter.sock
But it gets greylisted anyway:
May 31 12:02:13 hermione smtp/smtpd[58412]: connect from
66-220-155-148.mail-mail.facebook.com[66.220.155.148]
May
I have a whitelist file rna_rbl_whitelist_clients that contains:
# Part of smtpd_recipient_restrictions (greylisting is managed per recipient)
# These are the CLIENTS that are allowed to bypass greylisting
/\.facebook\.com$/ OK
/\.facebookmail\.com$/ OK
and th
On 2024-02-27 at 16:39:54 UTC-0500 (Tue, 27 Feb 2024 13:39:54 -0800
(PST))
lists--- via Postfix-users
is rumored to have said:
I have a sender_checks file but I don't see that on the postfix.org
website. Is that a deprecated parameter?
The names of Postfix map files are up to you. Their usag
Wietse:
> Your mistake: you are trying to match a SENDER ADDRESS with
> check_CLIENT_access.
lists--- via Postfix-users:
> Well do I put the domain in sender_access or sender_checks?
What do you want to not block: the sender email domain? Then
use check_sender_access (note that is check_sender_
Well do I put the domain in sender_access or sender_checks?
It looks like sender_access with an OK since it acts on the FROK field.
https://www.postfix.org/postconf.5.html
I have a sender_checks file but I don't see that on the postfix.org website. Is
that a deprecated parameter?
Feb 27, 2024
Your mistake: you are trying to match a SENDER ADDRESS with
check_CLIENT_access.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
I still have that problem with the sender that used a spammy microsoft
server that gets rejected by IP for using spamcop. I put the domain in
the client_checks file but the sender gets bounced.
postconf mail_version
mail_version = 3.8.1
compatibility_level = 2
The client_checks line was added
om an IP
not in their SPF record.
Oct 10 07:55:17 mail01 policyd-spf[590801]: 550 5.7.23 Message rejected due
to: SPF fail - not authorized. Please see
http://www.openspf.net/Why?s=mfrom;id=depositretu...@mycuservices.com;ip=74.203.184.40;r=
However, whitelisting it also brings in all of the se
On 11/3/2022 1:24 PM, Alex wrote:
In my rush between projects, I not only confused sqlgrey with
postscreen, but I also forgot that I already have a postscreen
section as well:
postscreen_access_list =
permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr,
ci
e following to my sqlgrey FQDN whitelisting entries, but
somehow it's still being rejected:
*.myworkday.com
generalatlantic.com
And the IP range to the IP whitelist:
209.177.165.0/24
Here is my smtpd_recipient_restrictions:
smtpd_recipient_restrictions =
reject_non_fqdn_recipie
>
>
> > This appears to indicate that generalatlantic.com is using the workday
> > service to send email, but the generalatlantic.com SPF record does not
> > include myworkday.com on the list of authorized senders.
> >
> > I've added the following to
ay_supp...@generalatlantic.com;ip=209.177.165.161;r=;
> from= to=
> proto=ESMTP helo=
>
> This appears to indicate that generalatlantic.com is using the workday
> service to send email, but the generalatlantic.com SPF record does not
> include myworkday.com on the list of authorized s
tic.com;ip=209.177.165.161;r=>; from=mailto:workday_supp...@generalatlantic.com>> to=mailto:repo...@example.com>> proto=ESMTP helo=http://wd1-az-mail-nat.myworkday.com>>
...
I've added the following to my sqlgrey FQDN whitelisting entries,
but somehow it's still being re
ears to indicate that generalatlantic.com is using the workday
service to send email, but the generalatlantic.com SPF record does not
include myworkday.com on the list of authorized senders.
I've added the following to my sqlgrey FQDN whitelisting entries, but
somehow it's still being
On Tue, 15 Feb 2022, 8:03 pm Wietse Venema, wrote:
>
>
> Perhaps it would be easier to look up SPF records and expand those
> into access lists? I'm sure somene did that 15 years ago.
>
>
>
Yes that's what postwhite apparently does by looking up SPF records. But I
noticed that some Google IPs in
Nitin N:
> Hi folks,
>
> I was looking at Postwhite to generate whitelist IP addresses for
> Postscreen. So I set up and ran it once to look at the list of IPs it
> generates. Then I randomly checked a Google IP that was there in my maillog
> and noticed that it was not there in Postwhite's list.
Hi folks,
I was looking at Postwhite to generate whitelist IP addresses for
Postscreen. So I set up and ran it once to look at the list of IPs it
generates. Then I randomly checked a Google IP that was there in my maillog
and noticed that it was not there in Postwhite's list. Well I do understand
Dnia 26.11.2021 o godz. 14:33:07 James B. Byrne pisze:
> In /usr/local/etc/postfix/postgrey_whitelist_clients.local we have dhs.gov:
>
> [root@mx31 ~]# grep dhs.gov
> /usr/local/etc/postfix/postgrey_whitelist_clients.local
>
> dhs.gov
>
> The problem is that postgrey grey-listed this email:
>
>
On Fri, November 26, 2021 14:40, Dino Edwards wrote:
> Did you try using
>
> .dhs.gov
>
No. As the man page does not indicate that this is correct syntax. I have made
that change however and will see it it makes a difference.
--
*** e-Mail is NOT a SECURE channel ***
Did you try using
.dhs.gov
In /usr/local/etc/postfix/postgrey_whitelist_clients.local?
-Original Message-
From: owner-postfix-us...@postfix.org On
Behalf Of James B. Byrne
Sent: Friday, November 26, 2021 2:33 PM
To: postfix-us...@cloud9.net
Subject: Postgrey - whitelisting
I looked for a postgrey list to ask this, but the one that I found does not
seem to have any archives after 2019 so I came here instead. If there is
somewhere else to ask this please let me know.
We use postfix with postgrey. We have a whitelist
/usr/local/etc/postfix/postgrey_whitelist_clients.
Lothar Schilling:
> Hi everybody,
>
> amongst other duties I am the adminstrator of another organisation's
> small (samba) server. Each day this server will send me its logs via
> email. Sadly, more often than not those emails get discarded by our
> relay server. Sometimes they fall victim to s
Hi everybody,
amongst other duties I am the adminstrator of another organisation's
small (samba) server. Each day this server will send me its logs via
email. Sadly, more often than not those emails get discarded by our
relay server. Sometimes they fall victim to smtpd_relay_restrictions
(bla
Wietse Venema skrev den 2020-10-27 20:58:
> smtpd_recipient_restrictions=
>check_sender_access hash:some-file
>check_sender_access cidr:other-file
On Tue, Oct 27, 2020 at 4:15 PM Benny Pedersen wrote:
would it not be
check_client_access for the cidr map ?
On 27.10.20 16:27, Joey J
I'm not sure, that's why I wanted to verify, I haven't used postfix since
2.11 so I have to get back into the details.
On Tue, Oct 27, 2020 at 4:15 PM Benny Pedersen wrote:
> Wietse Venema skrev den 2020-10-27 20:58:
>
> > smtpd_recipient_restrictions=
> >check_sender_access hash:some-file
Wietse Venema skrev den 2020-10-27 20:58:
smtpd_recipient_restrictions=
check_sender_access hash:some-file
check_sender_access cidr:other-file
would it not be
check_client_access for the cidr map ?
Joey J skrev den 2020-10-27 20:44:
Hello All,
Trying to make sure I'm doing this correctly, both at the right point
within the mail communications and in the format of my hash file.
smtpd_recipient_restrictions=
check_sender_access hash:name of file
And within that file have both white & bl
Thank you Wietse, not only for replying to this messages and helping but
for everything you do!
I will use the CIDR format ( I'm remembering from an older version I
believe that didn't exist 2.11.11 )
For the domain names and or email addresses do you recommend a better
method?
And it's still OK t
Joey J:
> Hello All,
>
> Trying to make sure I'm doing this correctly, both at the right point
> within the mail communications and in the format of my hash file.
>
> smtpd_recipient_restrictions=
>check_sender_access hash:name of file
This may be OK, provded that you have reject_unauth_dest
Hello All,
Trying to make sure I'm doing this correctly, both at the right point
within the mail communications and in the format of my hash file.
smtpd_recipient_restrictions=
check_sender_access hash:name of file
And within that file have both white & blacklist like so:
youareok.com OK
yo
Dnia 6.10.2020 o godz. 18:30:28 Rick King pisze:
>
> Now our customer has subscribed to Shopify, which apparently sends
> messages using the customer's email address as the FROM address. Which
> results in a rejection with a 553 5.7.1 Sender address rejected: not
> logged in.
So I understand you
der_access using FROM addresses, but it
doesn't use IP's only MAIL FROM addresses.
My questions is, is it possible to whitelist the IP's from Shopify with this
config? The customer would prefer to use IP Whitelisting.
Best Regards,
--
Rick King
On 17 Dec 2019, at 9:24, Ieva Dav wrote:
Hi,
So i inherited an old postfix setup and we have:
smtpd_client_restrictions =
check_client_access hash:$conf_dir/whitelist,
reject_rbl_client blah
reject_rbl_client blahblah
etc
And it still blocks the domains i put in the whitelist.
Note
Ieva Dav skrev den 2019-12-17 15:24:
So i inherited an old postfix setup and we have:
smtpd_client_restrictions =
check_client_access hash:$conf_dir/whitelist,
change hash to cidr mapping
check_client_access is not domain names imho
reject_rbl_client blah
reject_rbl_client blahblah
On 17.12.19 16:24, Ieva Dav wrote:
smtpd_client_restrictions =
check_client_access hash:$conf_dir/whitelist,
reject_rbl_client blah
reject_rbl_client blahblah
etc
And it still blocks the domains i put in the whitelist. Google says to have
this in recipient restrictions instead, but that does
Hi,
So i inherited an old postfix setup and we have:
smtpd_client_restrictions =
check_client_access hash:$conf_dir/whitelist,
reject_rbl_client blah
reject_rbl_client blahblah
etc
And it still blocks the domains i put in the whitelist. Google says to have
this in recipient restrictions
Dominic
On Mon, Mar 27, 2017, at 09:45 AM, Dominic Raferd wrote:
> I think the rejection you are seeing is being generated by
> reject_unknown_sender_domain.
That's what I figured.
> OKing an email in one restriction list only affects tests later in that same
> list, not tests in
> other restri
On 27 March 2017 at 17:25, wrote:
> Hello,
>
> I'm getting the following log msg for a user (u...@example.com),
>
> Mar 26 13:22:19 bigben postfix/ps2/smtpd[32481]: NOQUEUE: reject:
> RCPT from chrelay.taleo.net[68.233.76.14]: 450 4.1.8
> : Sender address rejected: Domain not
> found; fro
Hello,
I'm getting the following log msg for a user (u...@example.com),
Mar 26 13:22:19 bigben postfix/ps2/smtpd[32481]: NOQUEUE: reject: RCPT
from chrelay.taleo.net[68.233.76.14]: 450 4.1.8
: Sender address rejected: Domain not found;
from= to= proto=ESMTP
helo=
in my Postfix 3.2 lo
On 31 January 2017 at 16:48, Roberto Fulgado wrote:
> Hi Dominic,
>
> Thanks for the reply. I think I got it to work the way I want it by using
> check_sender_access instead of check_client_access in the
> smtpd_recipient_restrictions section. Your suggestion got me
> looking closely at different
using sendmail for a long time. I have a question on
RBL
whitelisting. I have done internet search on how to do it but I can't seem
to whitelist
some senders.
From what I understand, I can only white list mail server's FQDN
or it's IP address.
Is there a way to white list by send
On 27 January 2017 at 23:47, Roberto Fulgado wrote:
> Hi All,
>
> First of all I wanted to let you know that I just recently started using
> postfix as our
> mail server. We've been using sendmail for a long time. I have a question on
> RBL
> whitelisting. I have done in
Hi All,
First of all I wanted to let you know that I just recently started using
postfix as our
mail server. We've been using sendmail for a long time. I have a
question on RBL
whitelisting. I have done internet search on how to do it but I can't
seem to whitelist
some senders.
> On Nov 18, 2016, at 1:01 PM, Phil Stracchino wrote:
>
> On 11/18/16 14:43, @lbutlr wrote:
>> On Nov 17, 2016, at 12:22 AM, Voytek wrote:
>>> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
>>> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
>>> Cl
On 11/18/16 14:43, @lbutlr wrote:
> On Nov 17, 2016, at 12:22 AM, Voytek wrote:
>> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
>> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
>> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Current
On Nov 17, 2016, at 12:22 AM, Voytek wrote:
> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
> Sending Spam See: http://www.sorbs
in main.cf[1]
>
> so I should enter gmail into /etc/postfix/client_checks , yes?
>
> do I need all google smtp published IPs, OR, can I just have like:
>
> gmail.com OK
> google.com OK ?
Yes, whitelisting "gmail.com" and "google.com" clients should tak
On 11/17/2016 2:22 AM, Voytek wrote:
> just noticed some email sent from gmail/google bouncing from my server as
> sorbs RBL had that server/host listed;
>
> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavaila
just noticed some email sent from gmail/google bouncing from my server as
sorbs RBL had that server/host listed;
Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
Client host [209.85.217.170] blocked using
On 8/26/2016 4:02 PM, /dev/rob0 wrote:
> On Fri, Aug 26, 2016 at 10:31:20PM +0300, Aggelos wrote:
>> Does this also apply for any REJECT or DEFER ?
>
> Reject actions are like permit actions; they end the processing of
> restrictions in that stage.
Postfix stops all restriction processing when i
On Fri, Aug 26, 2016 at 10:31:20PM +0300, Aggelos wrote:
> So any OK (or permit) is not final until all restriction stages are
> checked, right?
A permit (or reject) action is final IN THAT STAGE. It ends
processing of any further restrictions, e.g., in your
smtpd_client_restrictions stage, an
On 26/08/2016 04:34 μμ, /dev/rob0 wrote:
Some of your DNSBLs have been gone for many years. At least one
(spamcop) is best for scoring; not safe for outright blocking of
mail.
Shouldn't I keep at least one of these DNSBLs, like zen.spamhaus.org ?
On 26/08/2016 03:51 μμ, Alex JOST wrote:
This should work:
smtpd_helo_restrictions = permit_mynetworks,
check_client_access hash:/etc/postfix/maps/whitelisted_clients,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname
You were right...It worked indeed. :)
applies to the mail.
I see now. As Bill also said "Whitelisting on any basis only applies in
the scope of the restriction list where the whitelisting directive exists."
So any OK (or permit) is not final until all restriction stages are
checked, right?
Does this also apply for any REJECT or DEFER ?
On 26/08/2016 07:17 μμ, Bill Cole wrote:
But the smtpd_helo_restrictions come later in the order of checks,
isn't that so?
Yes, but you can't protect a message from smtpd_helo_restrictions with a
whitelist in smtpd_client_restrictions.
I see.
On 8/26/2016 10:59 AM, Aggelos wrote:
>
> Then it should stop checking when it matches by IP the OK in
> /etc/postfix/maps/whitelisted_clients, right?
It stops checking smtpd_client_restrictions, and moves on to
smtpd_helo_restrictions.
*Each* smtpd_*_restrictions section must result in OK (or D
OK or PERMIT does not propagate from one restriction list
to the next. Whitelisting on any basis only applies in the scope of the
restriction list where the whitelisting directive exists.
You are rejecting an unknown helo hostname, so the whitelist is never
even checked.
But the
On 26/08/2016 03:51 μμ, Alex JOST wrote:
This should work:
smtpd_helo_restrictions = permit_mynetworks,
check_client_access hash:/etc/postfix/maps/whitelisted_clients,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname
Will try it and see ...
On 26/08/2016 03:58 μμ, @lbutlr wrote:
On 26 Aug 2016, at 06:09, Aggelos wrote:
On 26/08/2016 02:53 μμ, Kiss Gabor (Bitman) wrote:
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname
Yet, in the logs I still get these reports (sampl
o the mail.
Many users find it simpler to keep all antispam restrictions in a
single stage, usually recipient restrictions, for this reason. See:
http://www.postfix.org/SMTPD_ACCESS_README.html
which explains the process better.
Now let's back up a bit: any time someone mentions "
On 26 Aug 2016, at 06:09, Aggelos wrote:
> On 26/08/2016 02:53 μμ, Kiss Gabor (Bitman) wrote:
>>> smtpd_helo_restrictions = permit_mynetworks,
>>>reject_invalid_helo_hostname,
>>>reject_unknown_helo_hostname
>>
>>
>>> Yet, in the logs I still get these reports (sample on one line):
>>>
Am 26.08.2016 um 14:09 schrieb Aggelos:
On 26/08/2016 02:53 μμ, Kiss Gabor (Bitman) wrote:
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname
Yet, in the logs I still get these reports (sample on one line):
Aug 26 03:37:52 postfi
On 26/08/2016 02:53 μμ, Kiss Gabor (Bitman) wrote:
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname
Yet, in the logs I still get these reports (sample on one line):
Aug 26 03:37:52 postfix/smtpd[27675]: NOQUEUE: reject: RCPT fro
> smtpd_helo_restrictions = permit_mynetworks,
> reject_invalid_helo_hostname,
> reject_unknown_helo_hostname
> Yet, in the logs I still get these reports (sample on one line):
>
> Aug 26 03:37:52 postfix/smtpd[27675]: NOQUEUE: reject: RCPT from
> spam1.vodafone.gr[213.249.16.2]: 450 4.
I am trying to white list two client IPs:
213.249.16.2
213.249.16.3
I have put the following in /etc/postfix/maps/whitelisted_clients:
213.249.16.3 OK
213.249.16.2 OK
I have run postmap hash:<...etc...> and reloaded postfix.
main.cf ends like this:
--
:port. Both these are inconvenient
and prone to breakage because they're different from normal mail flow.
So... whitelisting (mime_)header_checks is not possible without
fragile infrastructure changes that don't scale well. And it's not
really whitelisting, it's exempting s
On 2016-05-27 12:21, wie...@porcupine.org wrote:
For fine-grained content management, use amavisd-new, perhaps as a
Okay, I am convinced, actually I am investigating how to integrate this
tool.
Yes, it is possible to use different header/body_checks on different
IP addresses. Unfortunately
to the alternate IP:port. Both these are inconvenient
and prone to breakage because they're different from normal mail flow.
So... whitelisting (mime_)header_checks is not possible without
fragile infrastructure changes that don't scale well. And it's not
really whitelis
Konstantin Kletschke:
> Hi,
>
> I wonder if there is a mechanism to implement a function to whitelist
> mime_header_checks or not.
Postfix header/body_checks are blunt tools, primarily to block known
bad email that no-one should receive.
For fine-grained content management, use amavisd-new, perh
Hi,
I wonder if there is a mechanism to implement a function to whitelist
mime_header_checks or not.
I read this is not possible, I also read this is possible with separate
cleanup (because header_checks and mime_header_cheks belongs to cleanup)
and smtpd in master.cf... 50:50
I have a mime_hea
Curtis:
+1 to the suggestion of properly using dnswl.org. But if you'd also like to
automatically scan the SPF records of mailers you trust (including Gmail)
and build an up-to-date Postscreen whitelist based on their published SMTP
servers, then Postwhite maybe of interest to you:
http://www.stevejenkins.com/blog/2015/11/postscreen-whitelisting-smtp-outbound-ip-addresses-large-webmail-providers/
SteveJ
> On Apr 10, 2016, at 5:37 PM, Curtis Villamizar
> wrote:
>
> In message
> "@lbutlr" writes:
>>
>> On Apr 10, 2016, at 10:24 AM, Curtis Villamizar =
>> wrote:
>>> postscreen_dnsbl_sites =3D
>>> list.dnswl.org*-5
>>> # followed by some blacklist sites
>>
>> It was my understanding th
Curtis Villamizar:
> btw- I don't think list.dnswl.org is a viable workaround for the post
> 220 problem. This just affects the dnsbl score which would already be
> zero. The post 220 checks would still be run before putting the gmail
> server IP into the temporary whitelist. Manual maintenance
On 11/04/16 11:37, Curtis Villamizar wrote:
> btw- I don't think list.dnswl.org is a viable workaround for the post
> 220 problem. This just affects the dnsbl score which would already be
> zero. The post 220 checks would still be run before putting the gmail
> server IP into the temporary whitel
In message
"@lbutlr" writes:
>
> On Apr 10, 2016, at 10:24 AM, Curtis Villamizar =
> wrote:
> > postscreen_dnsbl_sites =3D
> > list.dnswl.org*-5
> > # followed by some blacklist sites
>
> It was my understanding that eh the order of test said not matter
> because all the dnsbls list
@lbutlr:
> On Apr 10, 2016, at 10:24 AM, Curtis Villamizar =
> wrote:
> > postscreen_dnsbl_sites =3D
> > list.dnswl.org*-5
> > # followed by some blacklist sites
>
> It was my understanding that eh the order of test said not matter =
> because all the dnsbls listed would be checked, a
On Apr 10, 2016, at 10:24 AM, Curtis Villamizar
wrote:
> postscreen_dnsbl_sites =
> list.dnswl.org*-5
> # followed by some blacklist sites
It was my understanding that eh the order of test said not matter because all
the dnsbls listed would be checked, a final score computed, and the
In message <570a341b.9000...@pajamian.dhs.org>
Peter writes:
>
> On 10/04/16 15:00, Curtis Villamizar wrote:
> > This is a workaround that shouldn't be needed.
> >
> > Any idea what the cause of this is? So far no legit mail except gmail
> > gets caught here.
>
> gmail uses hundreds, or thousa
In message <3qjz5d5s15zj...@spike.porcupine.org>
Wietse Venema writes:
>
> Curtis Villamizar:
> > Since I enabled postscreen (with soft_bounce=yes in master.cf) I was
> > getting logs of this form:
> >
> > Apr 9 01:08:12 mta1 postfix/postscreen[18326]:
> > NOQUEUE: reject: RCPT from [2607:f8b0
Curtis Villamizar:
> Since I enabled postscreen (with soft_bounce=yes in master.cf) I was
> getting logs of this form:
>
> Apr 9 01:08:12 mta1 postfix/postscreen[18326]:
> NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999:
> 450 4.3.2 Service currently unavailable;
> from=, to=,
>
On Sat, Apr 09, 2016 at 11:00:53PM -0400, Curtis Villamizar wrote:
> Any idea what the cause of this is? So far no legit mail except gmail
> gets caught here.
Don't use after-greeting tests in postscreen. The postscreen
documentation explains exactly why this happens.
Bastian
--
"What
On 10/04/16 15:00, Curtis Villamizar wrote:
> This is a workaround that shouldn't be needed.
>
> Any idea what the cause of this is? So far no legit mail except gmail
> gets caught here.
gmail uses hundreds, or thousands of MTAs and has the unique property
that when they retry after a deferral i
In message <5709c8c8.1050...@megan.vbhcs.org>
Noel Jones writes:
> On 4/9/2016 10:00 PM, Curtis Villamizar wrote:
> > Since I enabled postscreen (with soft_bounce=yes in master.cf) I was
> > getting logs of this form:
> >
> > Apr 9 01:08:12 mta1 postfix/postscreen[18326]:
> > NOQUEUE: reject:
On 4/9/2016 10:00 PM, Curtis Villamizar wrote:
> Since I enabled postscreen (with soft_bounce=yes in master.cf) I was
> getting logs of this form:
>
> Apr 9 01:08:12 mta1 postfix/postscreen[18326]:
> NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999:
> 450 4.3.2 Service currently una
Since I enabled postscreen (with soft_bounce=yes in master.cf) I was
getting logs of this form:
Apr 9 01:08:12 mta1 postfix/postscreen[18326]:
NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999:
450 4.3.2 Service currently unavailable;
from=, to=,
proto=ESMTP, helo=
linefeeds add
smtpd_CLIENT_restrictions=
reject_unknown_reverse_client_hostname <- applies to everyone
check_RECIPIENT_access hash:/etc/postfix/unknown_client_override
reject_unknown_client_hostname <- applies to those not in the file
Yes, that will work, as long as you keep the default
"smtpd_de
On 11/24/2015 4:38 PM, Homer Wilson Smith wrote:
>
> Dear Gentle Folk,
>
> Postfix rocks!
>
> Running postfix 2.8.2
>
> I was using reject_unknown_reverse_client_hostname for many years.
>
> But too much spam was getting through and bogging my barracuda to
> its knees
Dear Gentle Folk,
Postfix rocks!
Running postfix 2.8.2
I was using reject_unknown_reverse_client_hostname for many years.
But too much spam was getting through and bogging my barracuda to
its knees with delayed mail etc. This is AFTER greylisting!
I am now using
Wietse Venema:
> Sebastian Wiesinger:
> > Hello,
> >
> > the documentation states:
> >
> > The milter_header_checks mechanism could also be used for
> > whitelisting. For example it could be used to skip heavy content
> > inspection for DKIM-signed
Sebastian Wiesinger:
> Hello,
>
> the documentation states:
>
> The milter_header_checks mechanism could also be used for
> whitelisting. For example it could be used to skip heavy content
> inspection for DKIM-signed mail from known friendly domains.
>
> I want to d
Hello,
the documentation states:
The milter_header_checks mechanism could also be used for
whitelisting. For example it could be used to skip heavy content
inspection for DKIM-signed mail from known friendly domains.
I want to do that for mail that passes DMARC checks (with 2.11.2 DMARC
became
On 30 Sep 2014, at 10:53, Mai Ling wrote:
Every now and then people ask for ways to skip some or all checks
defined
in header_checks done by the cleanup daemon, then they learn[1] that
due to
postifx design they must figure out workarounds or use external
filters.
It seems that you may not h
Am 30.09.2014 um 16:53 schrieb Mai Ling:
> What do you folks use to workaround such limitations while (ab)using
> cleanup's
> header_checks as a spam filter to whitelist the business needs?
just not use it for that or only in cases without any "but" or "if"
as combination with other filters
th
1 - 100 of 309 matches
Mail list logo
