Re: Best way to block X-Mail-Agent

2014-09-04 Thread Alberto Lepe
I added "header_checks" (regexp) to main.cf. I will test it. Thank you. On Fri, Sep 5, 2014 at 2:56 PM, Alberto Lepe wrote: > One of my customers is receiving a huge amount of "very specific" spam not > blocked by my regular postfix's spam control rules: > > The spam is coming from several ip a

Best way to block X-Mail-Agent

2014-09-04 Thread Alberto Lepe
One of my customers is receiving a huge amount of "very specific" spam not blocked by my regular postfix's spam control rules: The spam is coming from several ip addresses. All mails have this client: X-Mail-Agent: BSMTP DLL Feb 11 2001 by Tatsuo Baba Which would be the best way to block it?

Re: Problem with TLSA & CNAME Wildcard

2014-09-04 Thread Viktor Dukhovni
On Wed, Sep 03, 2014 at 02:40:09PM +, Viktor Dukhovni wrote: > $ dig +cd +dnssec +noall +comment +ans +auth -t tlsa > fail.mail2.clarion-hotels.cz > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63426 > ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORI

Re: more detail on lookup failures?

2014-09-04 Thread Ricardo Signes
* Wietse Venema [2014-09-04T15:55:07] > No. All match_list errors are logged with the match_error() function. First, let me note that I'm running 2.10.2. Here are all the syslog entries for cleanup for the last half hour on one host that's been having this problem. tl;dr: 32 occurances of mysql

Re: more detail on lookup failures?

2014-09-04 Thread Ricardo Signes
* Wietse Venema [2014-09-04T15:55:07] > Wietse Venema: > > If there is no logfile record with: > > > > warning: mysql query failed: [text from mysql_error() here] > > > > then either your syslog daemon lost that record, > > Yes. Thanks. I'll look harder, but this has happened many, many t

Re: more detail on lookup failures?

2014-09-04 Thread Wietse Venema
Wietse Venema: > If there is no logfile record with: > > warning: mysql query failed: [text from mysql_error() here] > > then either your syslog daemon lost that record, Yes. > or there was an > error while searching the etc/postfix/mysql_list_resend.cf "domains" > patterns and that error w

Re: more detail on lookup failures?

2014-09-04 Thread Wietse Venema
Ricardo Signes: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. > Lately, I'm seeing a lot more of this from some servers: > > postfix/cleanup[20330]: [ID 947731 mail.warning] > warning: mysql:/etc/postfix/mysql_list_resend.cf lookup error for > "[...]" > p

Re: Blocked via Spamhaus

2014-09-04 Thread Alex JOST
Am 04.09.2014 um 18:23 schrieb LuKreme: dwl.spamhaus.org=127.0.2.[2;3]*-3 swl.spamhaus.org=127.0.2.[12;13]*-3 AFAIR someone posted a few months ago that those lists are empty. Has that changed? -- Alex JOST

more detail on lookup failures?

2014-09-04 Thread Ricardo Signes
Lately, I'm seeing a lot more of this from some servers: postfix/cleanup[20330]: [ID 947731 mail.warning] warning: mysql:/etc/postfix/mysql_list_resend.cf lookup error for "[...]" postfix/cleanup[20330]: [ID 947731 mail.warning] warning: 6D0D222182: virtual_alias_maps map lookup pr

Re: Blocked via Spamhaus

2014-09-04 Thread Wietse Venema
LuKreme: > On 04 Sep 2014, at 10:44 , Wietse Venema wrote: > > LuKreme: > >> How does post screen decide which RBL to list in the log? > > > > It blames the DNSBL with the largest weight. > > > > The initial postscreen implementation blamed the DNSBL that replied > > first. That was considered

Re: Blocked via Spamhaus

2014-09-04 Thread Quanah Gibson-Mount
--On Thursday, September 04, 2014 1:47 PM -0400 Wietse Venema wrote: postscreen queries DNS[BW]Ls in parallel. The blame is based on the DNSBL weight, as described in my other follow-up. Ah, sorry, I should have noticed postscreen vs postfix. ;) --Quanah -- Quanah Gibson-Mount Server Arch

Re: Blocked via Spamhaus

2014-09-04 Thread LuKreme
On 04 Sep 2014, at 10:44 , Wietse Venema wrote: > LuKreme: >> How does post screen decide which RBL to list in the log? > > It blames the DNSBL with the largest weight. > > The initial postscreen implementation blamed the DNSBL that replied > first. That was considered misleading, especially wh

Re: Relay to another MTA on the same host

2014-09-04 Thread Wietse Venema
Konstantin: > Hello, > > I need to configure a second MTA on the same server. > You can tell that this does not make sense but this is a workaround for one > issue i have. > > Postfix listen on port 225 and another MTA on port 25. > postfix has transport_maps enabled > transport_maps = hash:/etc/

Re: Blocked via Spamhaus

2014-09-04 Thread Wietse Venema
Quanah Gibson-Mount: > --On Thursday, September 04, 2014 11:23 AM -0600 LuKreme > wrote: > > > About 95% of the rejections/blocked from postscreen show up as "blocked > > by zen.spamhaus.org" in the logs even though I have several other RBLs > > checked by postscreen. > > RBL rejections are gen

Re: Blocked via Spamhaus

2014-09-04 Thread Wietse Venema
LuKreme: > How does post screen decide which RBL to list in the log? It blames the DNSBL with the largest weight. The initial postscreen implementation blamed the DNSBL that replied first. That was considered misleading, especially when that DNSBL contributed very little to the total score.

Re: Blocked via Spamhaus

2014-09-04 Thread Quanah Gibson-Mount
--On Thursday, September 04, 2014 11:23 AM -0600 LuKreme wrote: About 95% of the rejections/blocked from postscreen show up as "blocked by zen.spamhaus.org" in the logs even though I have several other RBLs checked by postscreen. RBL rejections are generally done in order listed. You list z

Blocked via Spamhaus

2014-09-04 Thread LuKreme
About 95% of the rejections/blocked from postscreen show up as “blocked by zen.spamhaus.org” in the logs even though I have several other RBLs checked by postscreen. Almost all the ones that are not listing zen, are listing the DUL list, and the rest are listing “dnsbl.sorbs.net” (without a pref

Relay to another MTA on the same host

2014-09-04 Thread Konstantin
Hello, I need to configure a second MTA on the same server. You can tell that this does not make sense but this is a workaround for one issue i have. Postfix listen on port 225 and another MTA on port 25. postfix has transport_maps enabled transport_maps = hash:/etc/postfix/transport * smtp:[127.