On 5/17/2022 9:14 AM, White, Daniel E. (GSFC-770.0)[AEGIS] wrote:
This is part of what I plan to put on our new MTA (Postfix only) and MDA
(Postfix/Dovecot) servers.
Please tell me if I am doing anything foolish / dangerous.
My concern is whether I should put "permit_mynetworks" higher in the se
Excellent points.
And thanks for the access list tip.
I will lose the final reject from client and relay and exclude the MX servers
from mynetworks
Thanks.
On 5/17/22, 11:54, "owner-postfix-us...@postfix.org on behalf of Matus UHLAR -
fantomas"
wrote:
>> > smtpd_client_restrictions =
> smtpd_client_restrictions =
you'll block incoming mail with last reject.
This is right off of http://www.postfix.org/SMTPD_ACCESS_README.html#lists
/etc/postfix/main.cf:
# Allow connections from trusted networks only.
smtpd_client_restrictions = permit_mynetworks, reject
On 17.05.22 1
> > smtpd_client_restrictions =
> you'll block incoming mail with last reject.
This is right off of http://www.postfix.org/SMTPD_ACCESS_README.html#lists
/etc/postfix/main.cf:
# Allow connections from trusted networks only.
smtpd_client_restrictions = permit_mynetworks, reject
I only per
On 17.05.22 15:14, White, Daniel E. (GSFC-770.0)[AEGIS] wrote:
This is part of what I plan to put on our new MTA (Postfix only) and MDA
(Postfix/Dovecot) servers.
Please tell me if I am doing anything foolish / dangerous.
My concern is whether I should put "permit_mynetworks" higher in the sende
This is part of what I plan to put on our new MTA (Postfix only) and MDA
(Postfix/Dovecot) servers.
Please tell me if I am doing anything foolish / dangerous.
My concern is whether I should put "permit_mynetworks" higher in the sender and
recipient restrictions.
smtpd_client_restrictions =
Jan Ceuleers:
[ Charset windows-1252 converted... ]
> On 12/06/16 02:05, Wietse Venema wrote:
> > Wietse Venema:
> >> I have changed the text to:
> >>
> >> Otherwise it replies with the query arguments plus an empty
> >> address list and the reply TTL. The reply TTL is -1 if no
> >>
On 12/06/16 02:05, Wietse Venema wrote:
> Wietse Venema:
>> I have changed the text to:
>>
>> Otherwise it replies with the query arguments plus an empty
>> address list and the reply TTL. The reply TTL is -1 if no
>> reply is received, or if the reply contains no TTL information)
Wietse Venema:
> I have changed the text to:
>
> Otherwise it replies with the query arguments plus an empty
> address list and the reply TTL. The reply TTL is -1 if no
> reply is received, or if the reply contains no TTL information).
Final version:
Otherwise it replies wi
Peter:
> On 07/06/16 22:29, Wietse Venema wrote:
> > Otherwise it replies with the query arguments plus an empty
> > address list and the reply TTL (-1 if unavailable).
> >
> > "otherwise" means that the IP address is not listed, or that no
> > reply was received.
> >
> > I have changed t
On 08/06/16 07:23, Bill Cole wrote:
> postconf(5) says:
>
> postscreen_dnsbl_min_ttl (default: 60s)
>
> So by default, postscreen will not query dnsblog regarding a specific
> address and DNSBL for 60 seconds after dnsblog has returned a TTL in the
> 0-60 range for that address and DNSBL.
Correc
On 08/06/16 08:48, Peter wrote:
>> I have changed the text to:
>>
>> Otherwise it replies with the query arguments plus an empty
>> address list and the reply TTL. The reply TTL is -1 if no
>> reply is received, or if the reply contains no TTL information).
>
> That still doesn't
On 07/06/16 22:29, Wietse Venema wrote:
> Otherwise it replies with the query arguments plus an empty
> address list and the reply TTL (-1 if unavailable).
>
> "otherwise" means that the IP address is not listed, or that no
> reply was received.
>
> I have changed the text to:
>
>
On 6 Jun 2016, at 16:51, Peter wrote:
On 07/06/16 01:07, Bill Cole wrote:
4. The resolver cache honors (as most do) a DNSBL's negative cache
TTL
which is less than 60 seconds, e.g. Spamcop (0 seconds) or the
various
Spamhaus lists (10) and others.
postscreen (specifically dnsblog(8)) honors
Peter:
[ Charset windows-1252 converted... ]
> On 07/06/16 12:23, Wietse Venema wrote:
> >> dnsblog(8) states, "Otherwise it replies with the query arguments plus
> >> an empty address list and the reply TTL (-1 if unavailable)." It is
> >> unclear that this references the negative cache TTL as re
On 07/06/16 12:23, Wietse Venema wrote:
>> dnsblog(8) states, "Otherwise it replies with the query arguments plus
>> an empty address list and the reply TTL (-1 if unavailable)." It is
>> unclear that this references the negative cache TTL as returned by the
>> SOA record included in an NXDOMAIN r
Peter:
> On 03/06/16 22:20, Wietse Venema wrote:
> > Postscreen has postscreen_dnsbl_ttl (fixed time limit) or it uses
> > the DNS TTL, limited by postscreen_dnsbl_{min,max}_ttl.
> >
> > Please see Postfix documentatiom, and report a bug if it is incomplete.
>
> dnsblog(8) states, "Otherwise it r
On 07/06/16 01:07, Bill Cole wrote:
> 4. The resolver cache honors (as most do) a DNSBL's negative cache TTL
> which is less than 60 seconds, e.g. Spamcop (0 seconds) or the various
> Spamhaus lists (10) and others.
postscreen (specifically dnsblog(8)) honors this as well, but it's not
made entire
On 03/06/16 22:20, Wietse Venema wrote:
> Postscreen has postscreen_dnsbl_ttl (fixed time limit) or it uses
> the DNS TTL, limited by postscreen_dnsbl_{min,max}_ttl.
>
> Please see Postfix documentatiom, and report a bug if it is incomplete.
dnsblog(8) states, "Otherwise it replies with the query
On 5 Jun 2016, at 2:30, Peter wrote:
On 05/06/16 17:10, Michael Fox wrote:
Right. As I mentioned, I understand that part. My question was
about v3.1+
where the default for postscreen_dnsbl_min_ttl is only 60s. And, as
I
understand it, the defaults for v3.1 would cause both the postscreen
c
Got it. Thanks much Peter!
Michael
> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Peter
> Sent: Saturday, June 4, 2016 11:30 PM
> To: postfix-users@postfix.org
> Subject: Re: RBLs in pos
On 05/06/16 17:10, Michael Fox wrote:
> Right. As I mentioned, I understand that part. My question was about v3.1+
> where the default for postscreen_dnsbl_min_ttl is only 60s. And, as I
> understand it, the defaults for v3.1 would cause both the postscreen cache
> ttl and the system resolver's
> If postscreen_dnsbl_ttl or postscreen_dnsbl_min_ttl is 3600 (1 hour) but
> the minimum TTL field of the DNSBL's SOA record is 10 (as it is for the
> SBL) then postscreen will cache the lack of a DNSBL entry for as much as
> 59 minutes and 50 seconds longer than a proper caching resolver, which
>
On 4 Jun 2016, at 1:52, Michael Fox wrote:
[Quoting me]
As noted by Allen Coates, if postscreen_dnsbl_ttl (v2.8-v3.0) or
postscreen_dnsbl_min_ttl (3.1) is higher than the negative cache TTL
for
a DNSBL, postscreen can 'PASS OLD' an IP which has been listed in the
period since its prior connec
> > And, conversely, DNSBLs with
> > weights < postscreen_dnsbl_threshold should not be listed in
> > smtpd_*_restrictions because they could block an email on their own,
> > even
> > though they are not trusted to do so by postscreen.
>
> Not in all case
On 2 Jun 2016, at 12:45, Michael Fox wrote:
So, as I understand it: as long as the weight assigned to a DNSBL in
postscreen is >= postscreen_dnsbl_threshold, then there is no harm in
also
adding the same DNSBL to smtpd_*_restrictions.
True.
But this is not the whole story...
> 1) Given that DNSBLs in postscreen_dnsbl_sites and smtpd_*_restrictions use
> the same caching resolver and the same timeouts, they should produce the
> same result. Correct?
Each smtpd process has a short-lived cache (process lifetime).
Postscreen has postscreen_dnsbl_ttl (fixe
sites and smtpd_*_restrictions use
the same caching resolver and the same timeouts, they should produce the
same result. Correct? If so, then is there any reason at all for putting a
DNSBL in smtpd_*_restrictions if postscreen is already set up with a set of
weighted DNSBLs? Or, put another way, is
Michael Fox:
> > On 02/06/16 17:45, Michael Fox wrote:
> > > If a DNSBL in postscreen_dnsbl_sites has a weight >=
> > > postscreen_dnsbl_threshold, then is there any advantage to also
> > > listing it in smtpd_*_restrictions? For example, is there some fail
On 02/06/16 19:21, Michael Fox wrote:
>> On 02/06/16 17:45, Michael Fox wrote:
>>> If a DNSBL in postscreen_dnsbl_sites has a weight >=
>>> postscreen_dnsbl_threshold, then is there any advantage to also
>>> listing it in smtpd_*_restrictions? For example,
> On 02/06/16 17:45, Michael Fox wrote:
> > If a DNSBL in postscreen_dnsbl_sites has a weight >=
> > postscreen_dnsbl_threshold, then is there any advantage to also
> > listing it in smtpd_*_restrictions? For example, is there some failure
> > mode that having the DNS
On 02/06/16 17:45, Michael Fox wrote:
> If a DNSBL in postscreen_dnsbl_sites has a weight >=
> postscreen_dnsbl_threshold, then is there any advantage to also
> listing it in smtpd_*_restrictions? For example, is there some failure
> mode that having the DNSBL listed in both place
> Michael Fox:
> > Clarification: I seem to recall someone asking whether they should
> leave
> > RBLs in the smtpd_*_restrictions now that they've added them to
> postscreen.
> > And I seem to recall that the answer was something like "why not, it
> doe
Michael Fox:
> Clarification: I seem to recall someone asking whether they should leave
> RBLs in the smtpd_*_restrictions now that they've added them to postscreen.
> And I seem to recall that the answer was something like "why not, it doesn't
> hurt". But i
Clarification: I seem to recall someone asking whether they should leave
RBLs in the smtpd_*_restrictions now that they've added them to postscreen.
And I seem to recall that the answer was something like "why not, it doesn't
hurt". But it seems to me that if would hurt b
I think I recall seeing something about this a while ago, but I can't find
it in the archives.
If I'm using several RBLs in postscreen_dnsbl_sites, each with its own
weighting, then what is the best practice for using at least some of those
RBLs in smtpd_*_restrictions, or not?
VR a écrit :
> Is there a limit to how many check_*_access hash, pcre, regex files you
> can have under a given restriction in postfix 2.3?
>
> Not specifically client_restrictions but this is the general idea:
>
> main.cf:
> smtpd_client_restrictions=
> check_client_access hash:/etc/postfix/reje
VR wrote:
> Is there a limit to how many check_*_access hash, pcre, regex files
> you can have under a given restriction in postfix 2.3?
>
> Not specifically client_restrictions but this is the general idea:
>
> main.cf:
> smtpd_client_restrictions=
> check_client_access hash:/etc/postfix/reject_by
Is there a limit to how many check_*_access hash, pcre, regex files you
can have under a given restriction in postfix 2.3?
Not specifically client_restrictions but this is the general idea:
main.cf:
smtpd_client_restrictions=
check_client_access hash:/etc/postfix/reject_by_ip
check_client_acces
On Jul 9, 2009, at 10:28 AM, Jon wrote:
Looking for some clarification to help me understand. Are
smtpd_*_restrictions processed in this order:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions
The
On 7/9/2009, Robert Lopez (rlopez...@gmail.com) wrote:
>> If these restriction mechanisms share a common hash file for their check,
>> for example:
>>
>> /etc/postfix/main.cf
>> ...
>> smtpd_client_restrictions = check_client_access
>> hash:/etc/postfix/access_hash ...
>> ...
>> smtpd_sender_rest
Jon wrote:
> Looking for some clarification to help me understand. Are
> smtpd_*_restrictions processed in this order:
>
> smtpd_client_restrictions
> smtpd_helo_restrictions
> smtpd_sender_restrictions
> smtpd_recipient_restrictions
> smtpd_data_restrictions
>
On Thu, Jul 9, 2009 at 8:28 AM, Jon wrote:
> Looking for some clarification to help me understand. Are
> smtpd_*_restrictions processed in this order:
>
> smtpd_client_restrictions
> smtpd_helo_restrictions
> smtpd_sender_restrictions
> smtpd_recipient_restrictions
>
Looking for some clarification to help me understand. Are
smtpd_*_restrictions processed in this order:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions
If these restriction mechanisms share a common
Darren Pilgrim a écrit :
> King Spook wrote:
>> I'm getting hit pretty hard with spam, and was hoping to reduce it a
>> bit by adding the following smtpd restrictions:
>>
>> smtpd_helo_restrictions = reject_invalid_helo_hostname,
>> reject_non_fqdn_helo_hostname
>> smtpd_sender_restrictions = rejec
King Spook wrote:
I'm getting hit pretty hard with spam, and was hoping to reduce it a
bit by adding the following smtpd restrictions:
smtpd_helo_restrictions = reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname
smtpd_sender_restrictions = reject_non_fdqn_sender
Is that safe to do?
Y
I'm getting hit pretty hard with spam, and was hoping to reduce it a
bit by adding the following smtpd restrictions:
smtpd_helo_restrictions = reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname
smtpd_sender_restrictions = reject_non_fdqn_sender
Is that safe to do?
My current smtpd restr
47 matches
Mail list logo
