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 =
On 11.06.21 13:46, Togan Muftuoglu wrote:
What are the $mua_helo_restrictions and $mua_sender_restrictions in the
master.cf and how are they supposed to be used ?
no default values. You can set defaults if you nees to set up the same
restrictions to ports 465 and 587.
How do they affect the r
> What are the $mua_helo_restrictions and $mua_sender_restrictions in the
> master.cf
http://www.postfix.org/master.5.html
-o name=value (short form)
Override the named main.cf configuration parameter.
The parameter value can refer to other parameters as $name etc., just like
in main.cf.
See pos
Hi,
What are the $mua_helo_restrictions and $mua_sender_restrictions in the
master.cf and how are they supposed to be used ?
How do they affect the restrictions for the submission if left commented ?
Thanks
Hi,
I'm cleaning up my postfix configs and am wondering if I can improve /
should change my _restrictions on postfix 3.3 / 3.5:
local postfix instance:
smtpd_client_restrictions =
permit_mynetworks
permit_sasl_authenticated
smtpd_helo_restrictions =
permit_mynet
fwiw, shared here long ago -- don't remember the origin
Restrictions execution order:
postscreen, smtpd_mumble_restrictions, milter SMTP command inspection,
smtpd_proxy_filter, header/body_checks, milter header/body inspection,
content_filter
Hello,
I have a private (firewalled) outgoing-emails-only setup with main.cf
containing (among others):
smtpd_recipient_restrictions =
reject_non_fqdn_recipient
reject_unknown_recipient_domain
permit_sasl_authenticated
reject
smtpd_milters =
[some local ip:port]
The (only)
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
tscreen AND smtpd_*_restrictions
>
> 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
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?
On 05-Dec-2013 12:40 am, "Viktor Dukhovni"
wrote:
>
> On Thu, Dec 05, 2013 at 12:23:50AM +0530, Nilesh Govindrajan wrote:
>
> > > > What am I missing?
> > >
> > > Don't let your PHP applications send mail to arbitrary addresses
> > > unless they are restricted to authenticated trusted users. If t
On Thu, Dec 05, 2013 at 12:23:50AM +0530, Nilesh Govindrajan wrote:
> > > What am I missing?
> >
> > Don't let your PHP applications send mail to arbitrary addresses
> > unless they are restricted to authenticated trusted users. If the
> > latter, make sure you have valid sender addresses recorde
On 05-Dec-2013 12:17 am, "Viktor Dukhovni"
wrote:
>
> On Wed, Dec 04, 2013 at 11:54:11PM +0530, Nilesh Govindrajan wrote:
>
> > I have a postfix server configured with following restrictions -
> >
> > smtpd_reject_unlisted_sender = yes
>
> You'll have implement this control in the PHP application
On Wed, Dec 04, 2013 at 11:54:11PM +0530, Nilesh Govindrajan wrote:
> I have a postfix server configured with following restrictions -
>
> smtpd_reject_unlisted_sender = yes
You'll have implement this control in the PHP application or submit email
via SMTP, rather than the sendmail(1) command.
On 05-Dec-2013 12:09 am, "Noel Jones" wrote:
>
> On 12/4/2013 12:33 PM, Nilesh Govindrajan wrote:
> > That's what I concluded. Posted just to clear my doubt.
> > What's the fix or workaround? All php applications use the mail
> > function.
>
>
> Change your PHP to use SMTP or a sendmail-compatible
On 12/4/2013 12:33 PM, Nilesh Govindrajan wrote:
> That's what I concluded. Posted just to clear my doubt.
> What's the fix or workaround? All php applications use the mail
> function.
Change your PHP to use SMTP or a sendmail-compatible wrapper such as
mini_smtp rather than sendmail(1).
-- N
On 05-Dec-2013 12:03 am, "Nilesh Govindrajan" wrote:
>
> That's what I concluded. Posted just to clear my doubt.
> What's the fix or workaround? All php applications use the mail function.
>
> On 05-Dec-2013 12:02 am, "Noel Jones" wrote:
>>
>> On 12/4/2013 12:24 PM, Nilesh Govindrajan wrote:
>> >
That's what I concluded. Posted just to clear my doubt.
What's the fix or workaround? All php applications use the mail function.
On 05-Dec-2013 12:02 am, "Noel Jones" wrote:
> On 12/4/2013 12:24 PM, Nilesh Govindrajan wrote:
> > I have a postfix server configured with following restrictions -
>
On 12/4/2013 12:24 PM, Nilesh Govindrajan wrote:
> I have a postfix server configured with following restrictions -
>
> smtpd_reject_unlisted_sender = yes
>
> smtpd_relay_restrictions = reject_unverified_recipient,
> permit_mynetworks, permit_sasl_authenticated, permit_auth_destination,
> reject
I have a postfix server configured with following restrictions -
smtpd_reject_unlisted_sender = yes
smtpd_relay_restrictions = reject_unverified_recipient,
permit_mynetworks, permit_sasl_authenticated, permit_auth_destination,
reject
smtpd_recipient_restrictions =
reject_rbl_client zen.s
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
KLaM Postmaster a écrit :
> Is the a readme or other document that that outlines an optimal order
> for smtp_*_restrictions.
>
>
> Sorry, I should have been a little more specific, I am talking about the
> order of the parameters with in a class of restriction (eg.
> smtp_r
On Mar 27, 2009, at 1:32 PM, KLaM Postmaster wrote:
Is the a readme or other document that that outlines an optimal order
for smtp_*_restrictions.
Sorry, I should have been a little more specific, I am talking about
the
order of the parameters with in a class of restriction (eg
KLaM Postmaster wrote:
> Is the a readme or other document that that outlines an optimal order
> for smtp_*_restrictions.
>
>
> Sorry, I should have been a little more specific, I am talking about the
> order of the parameters with in a class of restriction (eg.
> smtp_recipie
KLaM Postmaster wrote:
> Is the a readme or other document that that outlines an optimal order
> for smtp_*_restrictions.
> TIA
> JLA
>
http://www.postfix.org/SMTPD_ACCESS_README.html#lists
Is the a readme or other document that that outlines an optimal order
for smtp_*_restrictions.
Sorry, I should have been a little more specific, I am talking about the
order of the parameters with in a class of restriction (eg.
smtp_recipient_restrictions), not the order of the restriction
Is the a readme or other document that that outlines an optimal order
for smtp_*_restrictions.
TIA
JLA
Victor Duchovni schrieb:
I can't honestly recommend anything other than start with the
default:
I suspect, you are right :)
After another check of my logfiles, i reduced my restriction lists
to the following:
smtpd_client_restrictions = reject_unknown_reverse_client_hostname,
check_clien
On Thu, Jan 29, 2009 at 03:35:11AM +0100, Thomas wrote:
>
> Or would you add reject_unknown_sender_domain? It is already used in
> "smptp_recipient_restrictions:
>
>
> smtpd_recipient_restrictions = permit_mynetworks
> reject_unknown_recipient_domain permit_sasl_authenticated
> reject_unauth_de
Victor Duchovni wrote:
If you do that, you will notice that there is no documentation for
"reject_unknown_address", hence you should not use it (there is
no such restriction, if that is not clear by now).
Uh.
Thanx!
I changed to the following:
smtpd_sender_restrictions = check_sender_acces
On Thu, Jan 29, 2009 at 01:09:08AM +0100, Thomas wrote:
> hash:/etc/postfix/client_access
> smtpd_sender_restrictions = reject_unknown_address check_sender_access
> hash:/etc/postfix/sender_access
Don't make stuff up. Keep it simple, and use only what you have
understood after reading the corres
ghe wrote:
James Berwick wrote:
From the documentation:
check_client_access type:table
Search the specified access database for the client hostname, parent
domains, client IP address, or networks obtained by stripping least
significant octets. See the access(5) manual page for details.
Yo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Berwick wrote:
> Thomas wrote:
>> smtpd_client_restrictions = reject_invalid_hostname
>> check_client_access hash:/etc/postfix/client_access
>>
>> /etc/postfix/client_access:
>> REJECT
>>
>> But if i try to send a mail to an address listed in cl
Thomas wrote:
But if i try to send a mail to an address listed in client_access, it
get happily queued and delivered :-(
I suspect that i used the wrong restriction, the wrong hash/... thing
or whatever ...
Could you give a hint in the right direction?
Found it:
smtpd_recipient_restrictio
Thomas wrote:
smtpd_client_restrictions = reject_invalid_hostname
check_client_access hash:/etc/postfix/client_access
/etc/postfix/client_access:
REJECT
But if i try to send a mail to an address listed in client_access, it
get happily queued and delivered :-(
I suspect that i used the wron
Hello,
the command "postconf smtpd_client_restrictions
smtpd_sender_restrictions" shows the following:
smtpd_client_restrictions = reject_invalid_hostname check_client_access
hash:/etc/postfix/client_access
smtpd_sender_restrictions = reject_unknown_address check_sender_access
hash:/etc/postf
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
Alain Spineux wrote:
Hi
I've some question bout the smtp_*_restrictions
When smtpd_delay_reject=yes (the default) :
- May I expect the policies will be called in the expected order :
first the one from smtpd_client_restrictions (in the order they are
defined of course),
then the ones
Alain Spineux пишет:
Hi
I've some question bout the smtp_*_restrictions
Have you read http://www.postfix.org/SMTPD_ACCESS_README.html ?
When smtpd_delay_reject=yes (the default) :
- May I expect the policies will be called in the expected order :
first the one
Hi
I've some question bout the smtp_*_restrictions
When smtpd_delay_reject=yes (the default) :
- May I expect the policies will be called in the expected order :
first the one from smtpd_client_restrictions (in the order they are
defined of course),
then the ones from smtpd_sender_restric
81 matches
Mail list logo
