On 2013-03-27 23:11, Matthew Hall wrote:
I ran into a bit of an issue trying out fqrdns.pcre as recommended
here in this thread. The header in the file recommended adding it
into
smtpd_client_restrictions. However if I place it there, I end up
rejecting mail even from SASL authenticated
On Thu, Mar 28, 2013 at 11:09:58PM -0500, Stan Hoeppner wrote:
On 3/28/2013 8:03 AM, /dev/rob0 wrote:
If postscreen DNSBLs are your only protection, what happens if
your DNS breaks? Spam flood! Here too, Stan's PCRE list can help,
again, at least as a HELO check (client name checks won't
The table was created many years ago over an extended period of
time,...::
so, its outdated?
i think its better to use postscreen and a regular updated file like
DROP from spamhaus.
i refresh this DROP every hour. so maybe wrong listed candidates are
deleted in the refreshed
On Thu, Mar 28, 2013 at 11:15:02AM +0100, Marko Weber | ZBF wrote:
The table was created many years ago over an extended period of
time,...::
That was what Stan said, yes.
so, its outdated?
Let's scroll down through the mass of quoting over which you
top-posted and see what
On 3/28/2013 12:12 AM, Noel Jones wrote:
Yes, first match wins.
This needs to be *immediately* followed by what you stated way down
below, copied here:
- each smtpd_*_restrictions section must resolve to permit (or
empty) to accept mail. A permit in one smtpd_*_restrictions
section is not
On Thu, Mar 28, 2013 at 1:19 PM, Stan Hoeppner s...@hardwarefreak.com wrote:
I don't have the thread archived (it's been 8 years or so), so I'm
guessing here, but IIRC it took at least a half dozen or more emails
back-forth before I understood this lack or inheritance. Once I did,
and
On 3/28/2013 8:03 AM, /dev/rob0 wrote:
... maintaining it ... see? I would think that something which is
maintained generally isn't outdated. Depends how well the maintainer
maintains it, of course.
Precisely. Let me add that ISPs introduce new consumer rDNS strings
very infrequently.
On Tue, Mar 26, 2013 at 4:16 PM, Wietse Venema wie...@porcupine.org wrote:
Lima Union:
[ Charset ISO-8859-1 unsupported, converting... ]
Am 26.03.2013 19:36, schrieb Lima Union:
Wietse, ok, I'll disable the fqrdns check for now and check the chroot
configuration after I return from
Lima Union:
Mar 26 15:56:34 relay1 postfix/smtpd[2021]: warning: 64.191.105.74:
hostname 64-191-105-74.static.hostnoc.net verification failed: Name or
service not known
Yes, broken DNS happens. Instead of reject_unknown_client_hostname
you could use
On 3/27/2013 7:30 AM, Lima Union wrote:
Wietse, there's something I don't understand. I've commented out the
check_reverse_client_hostname_access,
Re-enable it.
reloaded postfix and am still
finding those DNS warnings (ie: hostname
77-121-229-206.dhcp.kram-city.net verification failed:
On 3/26/2013 1:29 PM, Lima Union wrote:
No ipv6 here and pdnsd is using 8.8.8.8 as DNS server.
Instead of using a caching DNS proxy daemon querying Google's public DNS
servers, I recommend you run a recursing caching resolver on your
Postfix host, such as PowerDNS recursor (I've been using it
Hello,
I ran into a bit of an issue trying out fqrdns.pcre as recommended
here in this thread. The header in the file recommended adding it into
smtpd_client_restrictions. However if I place it there, I end up
rejecting mail even from SASL authenticated client devices, if they
also match a rule
On 3/27/2013 5:11 PM, Matthew Hall wrote:
Hello,
I ran into a bit of an issue trying out fqrdns.pcre as recommended
here in this thread. The header in the file recommended adding it into
smtpd_client_restrictions. However if I place it there, I end up
rejecting mail even from SASL
On 3/27/2013 5:11 PM, Matthew Hall wrote:
I ran into a bit of an issue trying out fqrdns.pcre as recommended
here in this thread. The header in the file recommended adding it into
smtpd_client_restrictions.
The instructions I provide are examples, not a concise how-to. As with
any
On Wed, Mar 27, 2013 at 05:56:03PM -0500, Stan Hoeppner wrote:
Frankly I'm surprised anyone still uses the old multi-section
restrictions configuration these days.
Sometimes it's necessary for complex restrictions, but I think the
worst I've ever needed was 2-3 mumbles of
On 3/27/2013 5:39 PM, Noel Jones wrote:
One could argue the example included in the file should
be clearer
I'm open to suggestions. As long as the doc section doesn't end up
longer than the expression list.
(and it's missing the required '=').
Fixed. Thanks for catching this oversight
On Wed, Mar 27, 2013 at 3:56 PM, Stan Hoeppner s...@hardwarefreak.com wrote:
It seems pretty clear you need to convert to putting everything under
smtpd_recipient_restrictions. Makes things a lot easier. I give an
example of this in the instructions as well. Doing so gives you precise
I altered the restrictions according to the new advice:
relay_restrictions - removed
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
On 3/27/2013 6:15 PM, Stan Hoeppner wrote:
On 3/27/2013 5:39 PM, Noel Jones wrote:
One could argue the example included in the file should
be clearer
I'm open to suggestions. As long as the doc section doesn't end up
longer than the expression list.
I would suggest a fully-working
On 3/27/2013 7:07 PM, Matthew Hall wrote:
smtpd_relay_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
#check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
reject_unauth_destination
The above is wrong in two ways. First, anti-spam access lists
On 3/27/2013 7:18 PM, Matthew Hall wrote:
I altered the restrictions according to the new advice:
relay_restrictions - removed
there's no reason to remove the safety net.
smtpd_relay_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
Yes, these are
On Wed, Mar 27, 2013 at 7:20 PM, Noel Jones njo...@megan.vbhcs.org wrote:
On 3/27/2013 7:18 PM, Matthew Hall wrote:
I altered the restrictions according to the new advice:
relay_restrictions - removed
there's no reason to remove the safety net.
Makes sense. Corrected.
Your
On 3/27/2013 10:07 PM, Matthew Hall wrote:
One other question here. So, if I have a host which matches
permit_sasl_authenticated, but also matches one of the rejections
present in check_reverse_client_hostname_access, but
permit_sasl_authenticated comes first in recipient_restrictions, then
On Mon, Mar 25, 2013 at 10:52 AM, Noel Jones njo...@megan.vbhcs.org wrote:
On 3/25/2013 7:55 AM, Lima Union wrote:
On Sat, Mar 23, 2013 at 11:31 AM, Benny Pedersen m...@junc.eu wrote:
Ejaz skrev den 2013-03-23 11:49:
...
are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
very
On 3/26/2013 7:04 AM, Lima Union wrote:
On Mon, Mar 25, 2013 at 10:52 AM, Noel Jones njo...@megan.vbhcs.org wrote:
On 3/25/2013 7:55 AM, Lima Union wrote:
On Sat, Mar 23, 2013 at 11:31 AM, Benny Pedersen m...@junc.eu wrote:
Ejaz skrev den 2013-03-23 11:49:
...
are you missing
On 3/26/2013 7:04 AM, Lima Union wrote:
...
ok, it seems that for some reason the check is not being triggered
(#847) after a postfix reload and 24 hours of operation in a busy
server, any ideas?
So when you grep Please relay via ISP against your mail log you get
nothing? Do you have any
On Tue, Mar 26, 2013 at 1:17 PM, Stan Hoeppner s...@hardwarefreak.com wrote:
On 3/26/2013 7:04 AM, Lima Union wrote:
...
ok, it seems that for some reason the check is not being triggered
(#847) after a postfix reload and 24 hours of operation in a busy
server, any ideas?
So when you grep
Lima Union skrev den 2013-03-26 13:04:
853 #reject_unverified_recipient,
postconf -n
not just content listning from main.cf
your error might just be that you have # at random lines
Lima Union skrev den 2013-03-26 18:59:
what can I check?
dig +trace ipv4.google.com
are the trace with hostnames all places ?
if you are on ipv6 change ipv4 to ipv6
are you using forwarders that does not support dnssec ?
is it working if you use nameserver 8.8.8.8 in resolv.conf ?
Lima Union:
working. This MTA is behing a firewall, in a DMZ with a bidirectional
mapping (1:1). I issued a grep ': connect from' and everything shown
is 'connect from unknown[ip.add.re.ss]'. I'm using pdnsd for caching
purposes. My resolv.conf points to 127.0.0.1 and seems to be working
On Tue, Mar 26, 2013 at 3:14 PM, Benny Pedersen m...@junc.eu wrote:
Lima Union skrev den 2013-03-26 13:04:
853 #reject_unverified_recipient,
postconf -n
not just content listning from main.cf
your error might just be that you have # at random lines
ok, here it's (hostname/ip
On Tue, Mar 26, 2013 at 3:20 PM, Benny Pedersen m...@junc.eu wrote:
Lima Union skrev den 2013-03-26 18:59:
what can I check?
dig +trace ipv4.google.com
are the trace with hostnames all places ?
if you are on ipv6 change ipv4 to ipv6
are you using forwarders that does not support dnssec
On Tue, Mar 26, 2013 at 3:21 PM, Wietse Venema wie...@porcupine.org wrote:
Lima Union:
working. This MTA is behing a firewall, in a DMZ with a bidirectional
mapping (1:1). I issued a grep ': connect from' and everything shown
is 'connect from unknown[ip.add.re.ss]'. I'm using pdnsd for caching
Am 26.03.2013 19:36, schrieb Lima Union:
On Tue, Mar 26, 2013 at 3:21 PM, Wietse Venema wie...@porcupine.org wrote:
A common mistake is to turn on chroot operation in the master.cf
file without going through all the necessary steps to set up a
chroot environment. This causes Postfix daemon
Am 26.03.2013 19:36, schrieb Lima Union:
Wietse, ok, I'll disable the fqrdns check for now and check the chroot
configuration after I return from holidays
this is ONE char in the master.cf and if i where you i
would not make holidays as long a production server is
known misconfigured
ok,
Lima Union:
[ Charset ISO-8859-1 unsupported, converting... ]
Am 26.03.2013 19:36, schrieb Lima Union:
Wietse, ok, I'll disable the fqrdns check for now and check the chroot
configuration after I return from holidays
this is ONE char in the master.cf and if i where you i
would not
On Sat, Mar 23, 2013 at 11:31 AM, Benny Pedersen m...@junc.eu wrote:
Ejaz skrev den 2013-03-23 11:49:
How do I configure my postfix not to accept the emails which sent on
invalid address?, since morning we have been noticed that there huge
spam dictionary attack on our server, all originated
On 3/25/2013 7:55 AM, Lima Union wrote:
On Sat, Mar 23, 2013 at 11:31 AM, Benny Pedersen m...@junc.eu wrote:
Ejaz skrev den 2013-03-23 11:49:
...
are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
very interesting link, as I understand my postfix is not prepared for
pcre thus I
How clever would it be to deploy in production?
For every mail, checking 1600 regexes doesn't seem efficient to me.
Will it have any significant CPU usage?
On Sat, Mar 23, 2013 at 8:01 PM, Benny Pedersen m...@junc.eu wrote:
are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
--
On Sat, Mar 23, 2013 at 8:01 PM, Benny Pedersen m...@junc.eu wrote:
are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
On 3/25/2013 11:06 AM, Abhijeet Rastogi wrote: How clever would it
be to deploy in production?
For every mail, checking 1600 regexes doesn't seem efficient to
On 3/25/2013 8:52 AM, Noel Jones wrote:
...
are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
very interesting link, as I understand my postfix is not prepared for
pcre thus I won't be able to use it, right?
...
You can use this file as a regexp: type.
pcre is recommended as
On 3/25/2013 11:06 AM, Abhijeet Rastogi wrote:
How clever would it be to deploy in production?
I've been using it for over 3 years, the original REGEXP version for a
few months, then my PCRE 'version' after that. AFAIK the ISP crew who
created the original have had it in production for more
Ejaz:
How do I configure my postfix not to accept the emails which sent on invalid
address?,
It doesn't, unless you make a configuration error that causes
Postfix to actually accept mail for non-existent recipients.
http://www.postfix.org/DEBUG_README.html#mail
since morning we have been
Ejaz skrev den 2013-03-23 11:49:
How do I configure my postfix not to accept the emails which sent on
invalid address?, since morning we have been noticed that there huge
spam dictionary attack on our server, all originated emails are from
random IPs and random from address to the invalid
On 3/23/2013 9:31 AM, Benny Pedersen wrote:
Ejaz skrev den 2013-03-23 11:49:
How do I configure my postfix not to accept the emails which sent on
invalid address?, since morning we have been noticed that there huge
spam dictionary attack on our server, all originated emails are from
random
Am 23.03.2013 11:49, schrieb Ejaz:
How do I configure my postfix not to accept the emails which sent on
invalid address?, since morning we have been noticed that there huge
spam dictionary attack on our server, all originated emails are from
random IPs and random from address to the invalid
46 matches
Mail list logo
