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 client
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
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 Thu, Mar 28, 2013 at 1:19 PM, Stan Hoeppner 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 realized how much I'd have
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
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 w
"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 refreshe
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 Wed, Mar 27, 2013 at 7:20 PM, Noel Jones 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 smtpd_recipient_restrictions
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 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 li
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-work
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,
rejec
On Wed, Mar 27, 2013 at 3:56 PM, Stan Hoeppner 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
> control of restriction e
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 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 smtpd_mumble_restri
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 restric
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 auth
Im Auftrag von Matthew Hall
> 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 clie
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 in
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 f
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
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 reject_unknown_reverse
On Tue, Mar 26, 2013 at 4:16 PM, Wietse Venema 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 holidays
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
> 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 misconfi
Am 26.03.2013 19:36, schrieb Lima Union:
> On Tue, Mar 26, 2013 at 3:21 PM, Wietse Venema 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 processes to fa
On Tue, Mar 26, 2013 at 3:21 PM, Wietse Venema 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
>> purposes.
On Tue, Mar 26, 2013 at 3:20 PM, Benny Pedersen 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 dnsse
On Tue, Mar 26, 2013 at 3:14 PM, Benny Pedersen 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
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
>
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 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
On Tue, Mar 26, 2013 at 1:17 PM, Stan Hoeppner 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 "Please relay
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 3/26/2013 7:04 AM, Lima Union wrote:
> On Mon, Mar 25, 2013 at 10:52 AM, Noel Jones wrote:
>> On 3/25/2013 7:55 AM, Lima Union wrote:
>>> On Sat, Mar 23, 2013 at 11:31 AM, Benny Pedersen wrote:
Ejaz skrev den 2013-03-23 11:49:
>> ...
are you missing http://www.hardwarefreak
On Mon, Mar 25, 2013 at 10:52 AM, Noel Jones wrote:
> On 3/25/2013 7:55 AM, Lima Union wrote:
>> On Sat, Mar 23, 2013 at 11:31 AM, Benny Pedersen wrote:
>>> Ejaz skrev den 2013-03-23 11:49:
>>>
> ...
>>>
>>> are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
>>
>> very interesting link
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 tha
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 recomm
> On Sat, Mar 23, 2013 at 8:01 PM, Benny Pedersen 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 me.
>
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 wrote:
>
> are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
--
Regards,
Abh
On 3/25/2013 7:55 AM, Lima Union wrote:
> On Sat, Mar 23, 2013 at 11:31 AM, Benny Pedersen 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
On Sat, Mar 23, 2013 at 11: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 ou
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 ad
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 origi
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
g 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 recipient.
See http://www.postfix.org/STRESS_README.html if this is slowing
down your mail delivery, or just wait until it is over.
Wietse
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 recipient.
Thanks in advance for
48 matches
Mail list logo
