whitelisting to correct rbl false positives

[Voytek]

just noticed some email sent from gmail/google bouncing from my server as
sorbs RBL had that server/host listed;

Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
Sending Spam See: http://www.sorbs.net/lookup.shtml?209.85.217.170;
from= to= proto=ESMTP
helo=


what is correct way to whiltelist gmail/google

I have like this in main.cf[1]

so I should enter gmail into /etc/postfix/client_checks , yes?

do I need all google smtp published IPs, OR, can I just have like:

gmail.com OK
google.com OK ?

what other 'well known services' like google should I whitelist, yahoo,
hotmail ?

thanks for any pointers

[1]
...
smtpd_recipient_restrictions =.
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,.
 reject_non_fqdn_sender,.
 reject_non_fqdn_recipient,.
 reject_unlisted_recipient,.
 check_policy_service inet:127.0.0.1:,.
 permit_mynetworks,
 check_sasl_access hash:/etc/postfix/sasl_access
 permit_sasl_authenticated,
 reject_unauth_destination,
 check_recipient_access hash:/etc/postfix/recipient_no_checks,
 check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
 check_helo_access hash:/etc/postfix/helo_checks,
 check_sender_access hash:/etc/postfix/sender_checks,
 check_client_access hash:/etc/postfix/client_checks,
 check_client_access pcre:/etc/postfix/client_checks.pcre,
 reject_rbl_client zen.spamhaus.org,
 reject_rhsbl_client dbl.spamhaus.org,
 reject_rhsbl_sender dbl.spamhaus.org,
...

Re: Veracode reported vulnerabilities

[Mc Secuirty]

Wietse:

Thank you very much for the response. I will look at the remaining two
items to see if they are also false positives based on the information you
provided for the other items. If I can't, I will try to get the lines
numbers at least for those two.

Thanks
Mc.

On Wed, Nov 16, 2016 at 7:54 PM, Wietse Venema  wrote:

> McSec:
> > A Veracode scan reported the following vulnerabilites in postfix 3.0.1:
> >
> > vulnerabilitymodulesource
> > Buffer Over Flowdnsblog   home/.../src/dns/dns_rr.c
> > Buffer Over Flowsmtpd home/.../src/tls/tls_scache.c
>
> There is no line number information, therefore this information is
> not actionable.
>
> > Numeric Errors  dnsblog   home/.../src/dns/dns_rr.c 262
> > Numeric Errors  dnsblog   home/.../src/dns/dns_rr.c 302
>
> Both are not a vulnerability, because DNS replies don't contain 268
> million responses. The DNS reply count is a 16-bit number, and is
> therefore limited to 0..65535.
>
> > Numeric Errors  dnsblog   home/.../src/dns/dns_strtype.c 207
>
> Not a vulnerability, because the dns_type_map[] table with symbolic
> names for DNS record types is much smaller than 2 billion.  The DNS
> record type is a 16-bit number, therefore there can be only 65536
> different record types.
>
> > Numeric Errors  smtpd home/.../src/tls/tls_dane.c 1291
>
> Not a vulnerability, because the trust anchor file is owned by a
> trusted local user (root), and because that file will contain fewer
> than 2 billion entries.
>
> Wietse
>

Re: "mail forwarding loop" when Resending Email to Oneself.

[Wietse Venema]

Ralph Corderoy:
> Hi Bill,
> 
> > > If not, what's the closest to a specification?
> >
> > The documentation in the software that adds it. In this case
> > specifically the man page for postconf(5)
> 
> I'd already read that, e.g. prepend_delivered_header, and it doesn't
> describe Postfix's logic for producing "mail forwarding loop", e.g. does
> it only check on final delivery so if it's a relay then it doesn't care?

The Postfix code that ADDS the delivered-to header will 
report a loop if that header already exists.

Doing it otherwise (checking without adding, or adding without
checking) makes no sense.

Wietse

Re: Veracode reported vulnerabilities

[Wietse Venema]

McSec:
> A Veracode scan reported the following vulnerabilites in postfix 3.0.1:
> 
> vulnerabilitymodulesource
> Buffer Over Flowdnsblog   home/.../src/dns/dns_rr.c
> Buffer Over Flowsmtpd home/.../src/tls/tls_scache.c

There is no line number information, therefore this information is
not actionable.

> Numeric Errors  dnsblog   home/.../src/dns/dns_rr.c 262
> Numeric Errors  dnsblog   home/.../src/dns/dns_rr.c 302

Both are not a vulnerability, because DNS replies don't contain 268
million responses. The DNS reply count is a 16-bit number, and is
therefore limited to 0..65535.

> Numeric Errors  dnsblog   home/.../src/dns/dns_strtype.c 207

Not a vulnerability, because the dns_type_map[] table with symbolic
names for DNS record types is much smaller than 2 billion.  The DNS
record type is a 16-bit number, therefore there can be only 65536
different record types.

> Numeric Errors  smtpd home/.../src/tls/tls_dane.c 1291

Not a vulnerability, because the trust anchor file is owned by a
trusted local user (root), and because that file will contain fewer
than 2 billion entries.

Wietse

Re: Was the Dovecot working well?

[vod vos]

I hope fail2ban default ban rule will work,



or should we add some more rules to it?




 On 星期二, 15 十一月 2016 19:11:41 -0800Ron Wheeler 
rwhee...@artifact-software.com wrote 




On 15/11/2016 9:52 PM, Sean Greenslade wrote: 

 On Tue, Nov 15, 2016 at 04:21:17AM -0500, Ron Wheeler wrote: 

 Fail2ban might be able to do the whack-a-mole in a sensible manner 
that 

 allowed for innocent interruptions but banned the bad guys 

 For the kind of attempts I typically see, F2B won't do much. It's 

 usually not a brute force type of attach. Generally it's only a single 

 connection that either attempts to fingerprint the server (checking for 

 known vulns) or just tries a few "easy" passwords (e.g. root/root, 

 pi/raspberry). 

F2B is pretty flexible. 

You can say that any IP that fails to login on root or pi 3 times in a 

week should be banned for a month or forever if you really see a subtle 

attack. 

You have control of the frequency of log messages that constitute an attack. 

 

You can look for any string in the log so you can watch for the 

vulnerability probes as well as login attempts. 

 

Ron 

 

 I would suggest simple connection rate limiting and enforcing strong 

 passwords as a better (in my opinion) option. 

 

 --Sean 

 

 

 

 

-- 

Ron Wheeler 

President 

Artifact Software Inc 

email: rwhee...@artifact-software.com 

skype: ronaldmwheeler 

phone: 866-970-2435, ext 102 

 

Re: EDNS / DANE trouble with Microsoft mail.protection.outlook.com.

[Viktor Dukhovni]

On Wed, Nov 16, 2016 at 11:15:35PM +0100, Walter Doekes wrote:

> this week we stumbled upon an issue where we could not send mail to certain
> domains, for instance em...@umcg.nl.
> 
> Nov 16 17:04:08 mail postfix/smtp[13330]: warning:
> no MX host for umcg.nl has a valid address record
> Nov 16 17:04:08 mail postfix/smtp[13330]: 1D1D21422C2:
> to=, relay=none, delay=2257,
> delays=2256/0.02/0.52/0, dsn=4.4.3, status=deferred
> (Host or domain name not found. Name service error
> for name=umcg-nl.mail.protection.outlook.com type=A:
> Host not found, try again)
> 
> It turned out that this was the cause:
> 
>   $ dig MX umcg.nl +short
>   10 umcg-nl.mail.protection.outlook.com.
> 
>   $ dig NS mail.protection.outlook.com. +short
>   ns1-proddns.glbdns.o365filtering.com.
>   ns2-proddns.glbdns.o365filtering.com.
> 
>   $ dig A umcg-nl.mail.protection.outlook.com.  \
>   @ns1-proddns.glbdns.o365filtering.com. +edns +dnssec |
> grep FORMERR
>   ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 46904
>   ;; WARNING: EDNS query returned status FORMERR -
>   retry with '+nodnssec +noedns'

I can't reproduce your observations using unbound as the local
resolver:


$ dig +dnssec +ad +noall +comment +cmd +qu +ans +auth +nocl +nottl \
-t a umcg-nl.mail.protection.outlook.com

; <<>> DiG 9.10.4-P2 <<>> +dnssec +ad +noall +comment +cmd +qu +ans +auth 
+nocl +nottl -t a umcg-nl.mail.protection.outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10562
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;umcg-nl.mail.protection.outlook.com. INA

;; ANSWER SECTION:
umcg-nl.mail.protection.outlook.com. A 213.199.154.23
umcg-nl.mail.protection.outlook.com. A 213.199.154.87

Postfix will not directly query the remote nameserver, and in indeed
with DANE you're supposed to be configured to *only* query the
local resolver.  What resolver is that?  And how is it configured?

Once the A records come back insecure (AD=0), Postfix will not
query for TLSA records.

> Apparently some Microsoft Office 365 mail servers do not support EDNS and
> return FORMERR. This propagated through our DNS recursors as SERVFAIL and
> caused the lookup to fail.

FORMERR is the expected/standard respose in this case, and your
resolver is expected to fall back to non-EDNS queries.

> Some more digging revealed that EDNS was enabled on the query through
> `smtp_addr_list`:
> 
>  else if (smtp_tls_insecure_mx_policy > TLS_LEV_MAY)
> res_opt = RES_USE_DNSSEC;

That setting affects communication between Postfix and the local
resolver, it does control the options on the next hop query.

> The USE_DNSSEC causes the subsequent queries to use USE_EDNS0 with the DO
> flag and that killed our interoperability with the Microsoft Office 365 DNS.

This analysis is flawed.  Your resolver is not supposed to
unconditionally use EDNS upstream just because the local client is
using EDNS.

> - Apart from Microsoft upgrading their servers to 2016 and supporting EDNS,
> is this issue something postfix should handle?

The problem is your resolver.

> - Would postfix have handled FORMERR but not SERVFAIL and are my caching
> resolvers to blame?

The latter.

> - Should postfix retry the query without EDNS on unexpected errors?

No.

-- 
Viktor.

EDNS / DANE trouble with Microsoft mail.protection.outlook.com.

[Walter Doekes]

Hi there list,

this week we stumbled upon an issue where we could not send mail to 
certain domains, for instance em...@umcg.nl.



Nov 16 17:04:08 mail postfix/smtp[13330]: warning: no MX host for umcg.nl has a 
valid address record
Nov 16 17:04:08 mail postfix/smtp[13330]: 1D1D21422C2: to=, 
relay=none, delay=2257, delays=2256/0.02/0.52/0, dsn=4.4.3, status=deferred (Host or 
domain name not found. Name service error for 
name=umcg-nl.mail.protection.outlook.com type=A: Host not found, try again)


It turned out that this was the cause:

  $ dig MX umcg.nl +short
  10 umcg-nl.mail.protection.outlook.com.

  $ dig NS mail.protection.outlook.com. +short
  ns1-proddns.glbdns.o365filtering.com.
  ns2-proddns.glbdns.o365filtering.com.

  $ dig A umcg-nl.mail.protection.outlook.com.  \
  @ns1-proddns.glbdns.o365filtering.com. +edns +dnssec |
grep FORMERR
  ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 46904
  ;; WARNING: EDNS query returned status FORMERR -
  retry with '+nodnssec +noedns'


Apparently some Microsoft Office 365 mail servers do not support EDNS 
and return FORMERR. This propagated through our DNS recursors as 
SERVFAIL and caused the lookup to fail.


A temporary workaround was to preheat the DNS cache by manually querying 
said domain without EDNS and then flush the queue entries:


  $ dig A umcg-nl.mail.protection.outlook.com. \
  @ns1-proddns.glbdns.o365filtering.com. +noedns +nodnssec +short
  213.199.154.87
  213.199.154.23

  # postqueue -i THE_ITEM

But that's obviously not the right solution.


Some more digging revealed that EDNS was enabled on the query through 
`smtp_addr_list`:


 else if (smtp_tls_insecure_mx_policy > TLS_LEV_MAY)
res_opt = RES_USE_DNSSEC;

The USE_DNSSEC causes the subsequent queries to use USE_EDNS0 with the 
DO flag and that killed our interoperability with the Microsoft Office 
365 DNS.


The fix was then to lower `smtp_tls_insecure_mx_policy` from 5 (dane) to 
1 (may):


smtp_tls_dane_insecure_mx_policy=may   # default: dane


For the record, this miscommunication started on our servers since the 
2nd of November, according to the logs (although I cannot rule out if 
anything changed on our side.) Running postfix 3.1.0-3 (Ubuntu Xenial) here.



My questions -- finally:

- Apart from Microsoft upgrading their servers to 2016 and supporting 
EDNS, is this issue something postfix should handle?


- Would postfix have handled FORMERR but not SERVFAIL and are my caching 
resolvers to blame?


- Should postfix retry the query without EDNS on unexpected errors?

- Should the default smtp_tls_dane_insecure_mx_policy be set to 'dane'? 
Or should something more conservative be appropriate if it's able to 
cause this kind of miscommunication?




Thanks for your input.

Cheers,
Walter Doekes
OSSO B.V.

Re: regexp for allowing helo host

[Niklaas Baudet von Gersdorff]

L.P.H. van Belle [2016-11-16 13:59 +0100] :

> I suggest you read : 
> http://faculty.cs.niu.edu/~rickert/cf/bad-ehlo.html 
> 
> personaly i use the following. 
> smtpd_helo_restrictions =
> permit_mynetworks,
> check_helo_access pcre:/etc/postfix/pcre/helo.pcre
> check_helo_access hash:/etc/postfix/overrule/allow_helo_access.map
> reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname,
> reject_unknown_helo_hostname,
> reject_unauth_destination
> 
> and in the helo.pcre
> ## Namebase
> /^localhost$/   554 Don't use my own hostname
> /^localhost\.localdomain$/  554 Don't use my own hostname
> /^domain\.tld$/  554 Don't use my own domainname
> /^hostname\.domain\.tld$/  554 Don't use my own hostname
> 
> ## IP Based
> /^127\.0\.0\.1$/554 Don't use my own IP address
> /^\[127\.0\.0\.1\]$/554 Don't use my own IP address
> /^\:\:1$/   554 Don't use my own IP address
> /^\[\:\:1\]$/   554 Don't use my own IP address
> /^\1\.2\.3\.4$/ 554 Don't use my own IP address
> 
> And change domain.tld to you domain. 
> Here you need all names know to you server ( for accepting mail ) 
> And change ip 1.2.3.4 to you ip. 
> 
> The allow_helo_access.map is use for anoying customers to allow them. 
> I give them 2 weeks to fix there setup. 
> Also due to changes in dutch law, im oblgated to check the helo for 
> correctness. 
> 
> Normaly i just refer to these links.  
> rfc2821 section-3.6 en 4.1.1.1 en 10.3 en  rfc5321 section 2.3.5)
> https://www.ietf.org/rfc/rfc2821.txt
> https://www.ietf.org/rfc/rfc5321.txt
> 
> and lots of misconfigured exchange server ( most the .local domains ) 
> https://technet.microsoft.com/EN-US/library/jj657457(v=exchg.150).aspx 
> Lots of them forget to adjust the outgoing smtp connectos. 
> 
> And best of all. ( to avoid spam ) the use of postscreen. 
> Example: 
> ### Before-220 tests (postscreen / DNSBL)
> postscreen_greet_banner = $myhostname, checking blacklists, please 
> wait.
> postscreen_greet_wait = 3s
> postscreen_greet_ttl = 2d
> postscreen_access_list  =
> permit_mynetworks,
> cidr:/etc/postfix/cidr/postscreen_whitelist_access.cidr,
> cidr:/etc/postfix/cidr/drop.spamhaus-lasso.cidr
> postscreen_dnsbl_reply_map  = 
> pcre:/etc/postfix/pcre/postscreen_dnsbl_reply_map.pcre
> postscreen_blacklist_action = drop
> postscreen_dnsbl_action = enforce
> postscreen_greet_action = enforce
> postscreen_dnsbl_ttl= 2h
> postscreen_dnsbl_threshold  = 4
> postscreen_dnsbl_sites =
> b.barracudacentral.org*4
> bad.psky.me*4
> zen.spamhaus.org*4
> dnsbl.cobion.com*2
> bl.spameatingmonkey.net*2
> fresh.spameatingmonkey.net*2
> dnsbl.anonmails.de*2
> dnsbl.kempt.net*1
> dnsbl.inps.de*2
> bl.spamcop.net*2
> dnsbl.sorbs.net*1
> spam.dnsbl.sorbs.net*2
> psbl.surriel.com*2
> bl.mailspike.net*2
> rep.mailspike.net=127.0.0.[13;14]*1
> bl.suomispam.net*2
> bl.blocklist.de*2
> ix.dnsbl.manitu.net*2
> dnsbl-2.uceprotect.net
> hostkarma.junkemailfilter.com=127.0.0.3
> hostkarma.junkemailfilter.com=127.0.0.[2;4]*2
> # whitelists
> swl.spamhaus.org*-4
> list.dnswl.org=127.0.[0..255].[2;3]*-1
> rep.mailspike.net=127.0.0.[17;18]*-1
> rep.mailspike.net=127.0.0.[19;20]*-2
> hostkarma.junkemailfilter.com=127.0.0.1*-1
> 
> At this moment the antispam server behind this postfix setup, 
> is 99.7% spam free. 
> A good check for rbl servers : http://multirbl.valli.org/ 

Thanks for sharing your configuration and links. All very helpful
-- and multirbl.valli.org is a great tool!

Niklaas

Re: hacker or server problem

[lists]

‎That is a good tip. I see there are rate limiting parameters:
http://www.postfix.org/TUNING_README.html


  Original Message  
From: Fazzina, Angelo
Sent: Wednesday, November 16, 2016 6:38 AM
To: postfix-users@postfix.org
Subject: RE: hacker or server problem

I'm a little late to the party, but wouldn't configuring Anvil in Postfix stop 
this kind of stuff ?
-ALF

-Angelo Fazzina
Operating Systems Programmer / Analyst 
University of Connecticut,  UITS, SSG, Server Systems
860-486-9075

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of li...@lazygranch.com
Sent: Wednesday, November 16, 2016 6:00 AM
To: Patrick Chemla ; postfix-users@postfix.org
Subject: Re: hacker or server problem

The full cidr is blocked in the firewall. 


  Original Message  
From: Patrick Chemla
Sent: Wednesday, November 16, 2016 2:48 AM
To: postfix-users@postfix.org
Subject: Re: hacker or server problem

Le 16/11/2016 à 12:38, li...@lazygranch.com a écrit :
> On Wed, 16 Nov 2016 02:26:13 -0800
> "li...@lazygranch.com"  wrote:
>
>> On Wed, 16 Nov 2016 11:52:14 +0200
>> Patrick Chemla  wrote:
>>
>>> Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :
 Is this a hack or a server problem. IP was listed in abusedb
 about a year ago.

 
 Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from
 unknown[87.236.215.11] Nov 16 09:14:36 theranch
 postfix/smtpd[6094]: lost connection after AUTH from
 unknown[87.236.215.11] Nov 16 09:14:36 theranch
> 
> # bzgrep -e 87.236.215.11 maillog | wc -l
> 212
>
> Three lines per hack. Make that 70 attempts. The stats line messes up
> the line count.
> First entry:Nov 16 09:13:45
> Last entry: Nov 16 09:18:00
> 255 seconds
> 16.5 attempts a minute
>
16 Attempts per second, yes this is a hack attempt.

Protect yourself immediatly, even if he will surely need some (hundred 
of) thousands attempts to find a password.

Another problem is that he is taking your bandwith.

Patrick

Re: Veracode reported vulnerabilities

[Leonardo Rodrigues]

While scanners are a great tool, blindly taking their results as 
inquestionable true can lead to disasters. The Debian SSL keys 
generation disaster is a proof of that.


Em 16/11/16 13:38, McSec escreveu:

A Veracode scan reported the following vulnerabilites in postfix 3.0.1:

vulnerabilitymodulesource
Buffer Over Flow  dnsblog   home/.../src/dns/dns_rr.c
Buffer Over Flow  smtpd home/.../src/tls/tls_scache.c
Numeric Errorsdnsblog   home/.../src/dns/dns_rr.c 262
Numeric Errorsdnsblog   home/.../src/dns/dns_rr.c 302
Numeric Errorsdnsblog   home/.../src/dns/dns_strtype.c 207
Numeric Errorssmtpd home/.../src/tls/tls_dane.c 1291

I do not see these being reported in the mailing list previously. Are these
are real vulnerabilities or false positives?



--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertru...@solutti.com.br
My SPAMTRAP, do not email it

Re: "mail forwarding loop" when Resending Email to Oneself.

[Ralph Corderoy]

Hi Bill,

> > If not, what's the closest to a specification?
>
> The documentation in the software that adds it. In this case
> specifically the man page for postconf(5)

I'd already read that, e.g. prepend_delivered_header, and it doesn't
describe Postfix's logic for producing "mail forwarding loop", e.g. does
it only check on final delivery so if it's a relay then it doesn't care?

I did find mutt has

3.22. bounce_delivered

Type: boolean
Default: yes

When this variable is set, mutt will include Delivered-To headers
when bouncing messages.  Postfix users may wish to unset this
variable.  — http://www.mutt.org/doc/manual/

But that's again imprecise, e.g. is Postfix involvement anywhere along
the route a problem?

If the MTA imposes new rules that affect the MUA's behaviour then I'd
expect it to offer guidance as to the MUA's policy.  (I realise "new"
could mean several years old here, but it's still a change.)  Every MTA
and MUA cooking up their own policy seems wrong.  Deviations and
broken implementations are bad enough when an RFC does exist.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

Re: "mail forwarding loop" when Resending Email to Oneself.

[Bill Cole]

On 16 Nov 2016, at 7:43, Ralph Corderoy wrote:


Does an RFC cover Delivered-To?


No.


If not, what's the closest to a
specification?


The documentation in the software that adds it. In this case 
specifically the man page for postconf(5)

Re: Veracode reported vulnerabilities

[McSec]

I checked the source code for the reported Numeric Errors in the latest
release, the source code at the identified lines hasn't changed from 3.0.1.

I also checked the release notes for 3.0.2 and later. The reported
vulnerabilities are not addressed as per the notes.

We will upgrade to the latest release at the next opportunity, but I am
afraid Veracode will report the same issues since the source hasn't changed.

On Wed, Nov 16, 2016 at 8:56 AM, Bill Cole-3 [via Postfix] <
ml-node+s1071664n87323...@n5.nabble.com> wrote:

> On 16 Nov 2016, at 10:38, McSec wrote:
>
> > A Veracode scan reported the following vulnerabilites in postfix
> > 3.0.1:
>
> Just curious: why bother with analyzing an obsolete version? Latest
> releases are 3.1.3 and 3.0.7.
>
> Also, have you read the release notes for 3.0.{2..7}?
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://postfix.1071664.n5.nabble.com/Veracode-reported-
> vulnerabilities-tp87320p87323.html
> To unsubscribe from Veracode reported vulnerabilities, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Veracode-reported-vulnerabilities-tp87320p87325.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: regexp for allowing helo host

[Eric Abrahamsen]

Tanstaafl  writes:

> On 11/15/2016 6:11 PM, Bill Cole
>  wrote:
>> Be aware that if you use reject_unknown_helo_hostname you will have a 
>> steady stream of cases for which  you will have to make special 
>> exceptions. How steady that stream is depends more on your volume and 
>> diversity of legitimate mail than on how heavily spammed you are.
>
> What Bill is saying here is using reject_unknown_helo_hostname to
> outright reject clients will reject legitimate clients, so unless you
> have a good reason for doing so and know what you are doing and are
> prepared to handle issues like you are experiencing now, or don't do it.

Okay, thanks for all the responses. First of all, sorry for not
specifying this at the beginning:

smtpd_helo_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   check_helo_access regexp:/etc/postfix/helo_access,
   reject_invalid_helo_hostname,
   reject_unknown_helo_hostname

I had been under the impression that rejecting unknown hostnames was a
fairly normal thing to do (on my low-usage server, I've only had to add
two exceptions). If it isn't, I'll just take it out, I'm not set on
using it.

Thanks for the link, Louis.

Eric

Re: Veracode reported vulnerabilities

[Bill Cole]

On 16 Nov 2016, at 10:38, McSec wrote:

A Veracode scan reported the following vulnerabilites in postfix 
3.0.1:


Just curious: why bother with analyzing an obsolete version? Latest 
releases are 3.1.3 and 3.0.7.


Also, have you read the release notes for 3.0.{2..7}?

Re: milter to decode quoted-printable, base64, ...

[Bill Cole]

On 16 Nov 2016, at 0:42, Michael Fox wrote:

[...]
Yup.  But if the original message content is all plain text, then the 
encoding adds no value and can be removed without changing the 
message.


That is a critical factor.

It is entirely feasible to slice everything other than text/plain parts 
off of a multipart/{mixed,alternative} and reinject the remnant. An 
ideal tool for that is MIMEDefang, a milter that is often used as an 
alternative to Amavis (as a hub for anti-malware and anti-spam 
filtering,) but at its core is a toolkit for message manipulation and 
transformation. If you can define what you want to do in the 
transformation from encoded text to plain text to handle non-obvious 
cases as Perl code, you can do it in MIMEDefang and not have to code the 
plumbing yourself. MD uses the MIME-tools suite of Perl modules which is 
maintained by the same author (Dianne Skoll) so if you do pick it as 
your base tool for this, you'll already have a trivially easy-to-use way 
to decode text/plain parts encoded by Base64 or QP. Of course, once 
you've got a blob of decoded "text" (maybe in Latin-1 or UTF-8) you 
would then need to squash it down into a mail-safe form, for which 
"groff -T ascii" is your friend (if you befriend berserker vandals...)



I presume I need a content-filter to perform this work post-queue.


If you did this with MD or any other milter, the model would be to 
discard the original message pre-queue (i.e. have Postfix "accept" the 
message in SMTP but not queue it) and re-inject the transformed message.



One actually should only do anything like this with client-side
software. You presumably intend to throw away information (such as 
the

difference between o, ô, and ö)


Yes.  Although the likelihood of such characters in the original 
content is virtually nil in this application.  And, even if it does 
exist, such characters can't be used by the receiving client anyway.


OK, so there are tools like groff that will squash extended 8-bit 
supersets of ASCII into ASCII in a lossy manner. If you understand the 
real degree of damage that may do and can accept it on a known low-risk 
input stream, who am I to judge?


FWIW, I've done this sort of text normalization on a large messy 
collection of mixed text, html, and pdf files, many of which were at one 
point email. if you want to do an ideal transformation of everything it 
is insanely complex. If you can tolerate substantial damage to decoded 
non-ASCII input, "groff -T ascii" will do it and just drop non-ASCII 
characters.



and it is best to allow those choices
to remain with end users.


Generally true.  But not in this case.  The client is what it is.  So 
I either find a way to decode such messages externally before 
delivering them to the client, or else the messages can't be read at 
all (at least the base64 type).


OK, assuming that you understand what you're doing...


Solve whatever problem you are trying to solve in
some other way.


I understand and appreciate what you're saying as a general rule.  But 
I also understand this particular application.  And for this 
particular application, recovering the original plain text message 
before sending to the client is what's needed.


That raises an alternative option: if there *is* an "original plain text 
message" which something else is encoding, maybe the better approach is 
to fix the busybody encoder.


But thanks for your thoughts, Bill.  Your postings on this list are 
always informative.


Thank you. I try.

Re: regexp for allowing helo host

[Florian Piekert]

Am 16.11.2016 um 15:00 schrieb L.P.H. van Belle:

Hello,

> No, Thats is due my setup with the mailscanner antispam behind it.

What is so different in your pf configuration, that you do not encounter
these warnings?
Nov 16 17:08:31 blueberry postfix/postscreen[27495]: warning:
psc_dnsbl_request: connect to private/dnsblog service: Resource temporarily
unavailable
Nov 16 17:08:31 blueberry postfix/postscreen[27495]: message repeated 8
times: [ warning: psc_dnsbl_request: connect to private/dnsblog service:
Resource temporarily unavailable]

I have now 20 (!) dnsblog processes running and still I receive these warnings.

> Just give those sites a good read, and the adjust the config to your needs. 
> 
> Running a caching dns on that server helps dns queries. 

I have a full fledged bind9 running, doing exactly that...

> Extra to that, install fail2ban and add postfix-dnsbl.conf

Or is there something I miss, Wietse? Viktor?

Cheers,
Florian

===
Note:  this message was  send by me *only* if the  eMail message contains a
correct pgp signature corresponding to my address at  flo...@floppy.org. Do
you need my  PGP  public key? Check out http://www.floppy.org or send me an
email with  the subject "send pgp public key" to  this address of mine.Thx!



signature.asc
Description: OpenPGP digital signature

Veracode reported vulnerabilities

[McSec]

A Veracode scan reported the following vulnerabilites in postfix 3.0.1:

vulnerabilitymodulesource
Buffer Over Flow  dnsblog   home/.../src/dns/dns_rr.c
Buffer Over Flow  smtpd home/.../src/tls/tls_scache.c
Numeric Errorsdnsblog   home/.../src/dns/dns_rr.c 262
Numeric Errorsdnsblog   home/.../src/dns/dns_rr.c 302
Numeric Errorsdnsblog   home/.../src/dns/dns_strtype.c 207
Numeric Errorssmtpd home/.../src/tls/tls_dane.c 1291

I do not see these being reported in the mailing list previously. Are these
are real vulnerabilities or false positives?

Thanks
Mc.





--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Veracode-reported-vulnerabilities-tp87320.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Queue stuck with "Host or domain name not found", needs restart

[Stefan Monnier]

For the last few weeks, one of my machines (running Debian stable, with
Postfix 2.11.3) gets constantly stuck with things like:

% mailq
-Queue ID- --Size-- Arrival Time -Sender/Recipient---
CDC7364F79  972 Wed Nov 16 08:12:48  monn...@iro.umontreal.ca
(Host or domain name not found. Name service error for 
name=smtp.teksavvy.com type=: Host not found, try again)
 emacs-de...@gnu.org
 r...@gnu.org
 monn...@iro.umontreal.ca

[...]
-- 17 Kbytes in 4 Requests.

Yet `host smtp.teksavvy.com` (which is my relayhost which I set with
`relayhost = [smtp.teksavvy.com]` in my main.cf) responds very happily:

% host smtp.teksavvy.com
smtp.teksavvy.com has address 206.248.188.90
smtp.teksavvy.com has IPv6 address 2607:f2c0:1:2304::5
%

I expected `postqueue -f` to solve the problem, but it didn't.
Instead it just gives me messages in the log along the lines of:

Nov 16 09:32:07 pastel postfix/smtp[22671]: CDC7364F79: 
to=, relay=none, delay=4759, delays=4759/0.01/0/0, 
dsn=4.4.3, status=deferred (Host or domain name not found. Name service error 
for name=smtp.teksavvy.com type=: Host not found, try again)

Now, I can easily fix the problem with:

# /etc/init.d/postfix restart; postqueue -f

but why is it necessary to restart postfix before it notices that
whatever DNS problem might have occurred is long gone?

This problem re-appears pretty much every time I use the machine (it's
suspended in the mean time).

Any idea what my be the culprit and how to fix the problem (other thn
with a cron job that restarts postfix all the time)?


Stefan

RE: hacker or server problem

[Fazzina, Angelo]

I'm a little late to the party, but wouldn't configuring Anvil in Postfix stop 
this kind of stuff ?
-ALF

-Angelo Fazzina
Operating Systems Programmer / Analyst 
University of Connecticut,  UITS, SSG, Server Systems
860-486-9075

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of li...@lazygranch.com
Sent: Wednesday, November 16, 2016 6:00 AM
To: Patrick Chemla ; postfix-users@postfix.org
Subject: Re: hacker or server problem

The full cidr is blocked in the firewall. 


  Original Message  
From: Patrick Chemla
Sent: Wednesday, November 16, 2016 2:48 AM
To: postfix-users@postfix.org
Subject: Re: hacker or server problem

Le 16/11/2016 à 12:38, li...@lazygranch.com a écrit :
> On Wed, 16 Nov 2016 02:26:13 -0800
> "li...@lazygranch.com"  wrote:
>
>> On Wed, 16 Nov 2016 11:52:14 +0200
>> Patrick Chemla  wrote:
>>
>>> Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :
 Is this a hack or a server problem. IP was listed in abusedb
 about a year ago.

 
 Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from
 unknown[87.236.215.11] Nov 16 09:14:36 theranch
 postfix/smtpd[6094]: lost connection after AUTH from
 unknown[87.236.215.11] Nov 16 09:14:36 theranch
> 
> # bzgrep -e 87.236.215.11 maillog | wc -l
> 212
>
> Three lines per hack. Make that 70 attempts. The stats line messes up
> the line count.
> First entry:Nov 16 09:13:45
> Last entry: Nov 16 09:18:00
> 255 seconds
> 16.5 attempts a minute
>
16 Attempts per second, yes this is a hack attempt.

Protect yourself immediatly, even if he will surely need some (hundred 
of) thousands attempts to find a password.

Another problem is that he is taking your bandwith.

Patrick

Re: Load balance outgoing message

[Wietse Venema]

Marcelo Machado:
> Hi everybody.
> 
> Is possible with postfix send messages to multiple smart hosts randomly
> from a single domain?

This requires Postfix 3.0 and later:

/etc/postfix/main.cf:
default_transport = randmap:{smtp:[relayhost1], smtp:[relayhost2]}

The {} and [] are required.

This chooses randomly between relayhost1 and relayhost2.

Wietse

RE: regexp for allowing helo host

[L . P . H . van Belle]

Hai Florian, 

No, Thats is due my setup with the mailscanner antispam behind it.

Just give those sites a good read, and the adjust the config to your needs. 

Running a caching dns on that server helps dns queries. 
Extra to that, install fail2ban and add postfix-dnsbl.conf
With filter : 
failregex = NOQUEUE: reject: RCPT from (.*)\[\]:([0-9]{4,5}:)? 550 5.7.1 
Service unavailable; client \[(.*)\] blocked 

And this all helpt my traffic down about 5-10%. Not much but still. 


Greetz, 

Louis




> -Oorspronkelijk bericht-
> Van: flo...@floppy.org [mailto:owner-postfix-us...@postfix.org] Namens
> Florian Piekert
> Verzonden: woensdag 16 november 2016 14:39
> Aan: L.P.H. van Belle; postfix-users@postfix.org
> Onderwerp: Re: regexp for allowing helo host
> 
> Am 16.11.2016 um 14:35 schrieb L.P.H. van Belle:
> 
> I have those entries in the master.cf, except it's having the "n" for
> chrooted as well (should be transparent)...
> 
> I assume it is due to the sheer NUMBER of dnsbl sites to query
> simultaneously?
> 
> > Ah yes,
> >
> > In master.cf  adust these.
> >
> > smtp  inet  n   -   -   -   1   postscreen
> > smtpd pass  -   -   -   -   -   smtpd
> > dnsblog   unix  -   -   -   -   0   dnsblog
> >
> >
> >
> >> -Oorspronkelijk bericht-
> >> Van: flo...@floppy.org [mailto:owner-postfix-us...@postfix.org] Namens
> >> Florian Piekert
> >> Verzonden: woensdag 16 november 2016 14:27
> >> Aan: L.P.H. van Belle; postfix-users@postfix.org
> >> Onderwerp: Re: regexp for allowing helo host
> >>
> >> Am 16.11.2016 um 13:59 schrieb L.P.H. van Belle:
> >>
> >> After going from
> >> postscreen_dnsbl_sites =
> >>   zen.spamhaus.org*2,
> >>   bl.mailspike.net,
> >>   bl.spamcop.net,
> >>   b.barracudacentral.org,
> >>   swl.spamhaus.org*-2
> >> to
> >>> postscreen_dnsbl_sites =
> >>> b.barracudacentral.org*4
> >>> bad.psky.me*4
> >>> zen.spamhaus.org*4
> >>> dnsbl.cobion.com*2
> >>> bl.spameatingmonkey.net*2
> >>> fresh.spameatingmonkey.net*2
> >>> dnsbl.anonmails.de*2
> >>> dnsbl.kempt.net*1
> >>> dnsbl.inps.de*2
> >>> bl.spamcop.net*2
> >>> dnsbl.sorbs.net*1
> >>> spam.dnsbl.sorbs.net*2
> >>> psbl.surriel.com*2
> >>> bl.mailspike.net*2
> >>> rep.mailspike.net=127.0.0.[13;14]*1
> >>> bl.suomispam.net*2
> >>> bl.blocklist.de*2
> >>> ix.dnsbl.manitu.net*2
> >>> dnsbl-2.uceprotect.net
> >>> hostkarma.junkemailfilter.com=127.0.0.3
> >>> hostkarma.junkemailfilter.com=127.0.0.[2;4]*2
> >>> # whitelists
> >>> swl.spamhaus.org*-4
> >>> list.dnswl.org=127.0.[0..255].[2;3]*-1
> >>> rep.mailspike.net=127.0.0.[17;18]*-1
> >>> rep.mailspike.net=127.0.0.[19;20]*-2
> >>> hostkarma.junkemailfilter.com=127.0.0.1*-1
> >>
> >> I am rewarded with
> >> Nov 16 14:20:35 blueberry postfix/postscreen[18461]: warning:
> >> psc_dnsbl_request: connect to private/dnsblog service: Resource
> >> temporarily
> >> unavailable
> >> Nov 16 14:20:35 blueberry postfix/postscreen[18461]: message repeated 7
> >> times: [ warning: psc_dnsbl_request: connect to private/dnsblog
> service:
> >> Resource temporarily unavailable]
> >>
> >> Any idea?!
> >>
> >> I stopped pf, removed the postscreen_cache.db file just in case,
> restarted
> >> pf. Still getting those messages...
> 
> 
> 
> --
> 
> Florian Piekert, PMP
> flo...@floppy.org
> 
> Spargelweg 5Telephone+Fax: +49-179-
> 3928582
> 38179 Schwülper-Walle/Germany
> 
> ==
> =
> Note:  this message was  send by me *only* if the  eMail message contains
> a
> correct pgp signature corresponding to my address at  flo...@floppy.org.
> Do
> you need my  PGP  public key? Check out http://www.floppy.org or send me
> an
> email with  the subject "send pgp public key" to  this address of
> mine.Thx!
> 
> 

Re: regexp for allowing helo host

[Florian Piekert]

Am 16.11.2016 um 14:35 schrieb L.P.H. van Belle:

I have those entries in the master.cf, except it's having the "n" for
chrooted as well (should be transparent)...

I assume it is due to the sheer NUMBER of dnsbl sites to query simultaneously?

> Ah yes, 
> 
> In master.cf  adust these. 
> 
> smtp  inet  n   -   -   -   1   postscreen
> smtpd pass  -   -   -   -   -   smtpd
> dnsblog   unix  -   -   -   -   0   dnsblog
> 
> 
> 
>> -Oorspronkelijk bericht-
>> Van: flo...@floppy.org [mailto:owner-postfix-us...@postfix.org] Namens
>> Florian Piekert
>> Verzonden: woensdag 16 november 2016 14:27
>> Aan: L.P.H. van Belle; postfix-users@postfix.org
>> Onderwerp: Re: regexp for allowing helo host
>>
>> Am 16.11.2016 um 13:59 schrieb L.P.H. van Belle:
>>
>> After going from
>> postscreen_dnsbl_sites =
>>   zen.spamhaus.org*2,
>>   bl.mailspike.net,
>>   bl.spamcop.net,
>>   b.barracudacentral.org,
>>   swl.spamhaus.org*-2
>> to
>>> postscreen_dnsbl_sites =
>>> b.barracudacentral.org*4
>>> bad.psky.me*4
>>> zen.spamhaus.org*4
>>> dnsbl.cobion.com*2
>>> bl.spameatingmonkey.net*2
>>> fresh.spameatingmonkey.net*2
>>> dnsbl.anonmails.de*2
>>> dnsbl.kempt.net*1
>>> dnsbl.inps.de*2
>>> bl.spamcop.net*2
>>> dnsbl.sorbs.net*1
>>> spam.dnsbl.sorbs.net*2
>>> psbl.surriel.com*2
>>> bl.mailspike.net*2
>>> rep.mailspike.net=127.0.0.[13;14]*1
>>> bl.suomispam.net*2
>>> bl.blocklist.de*2
>>> ix.dnsbl.manitu.net*2
>>> dnsbl-2.uceprotect.net
>>> hostkarma.junkemailfilter.com=127.0.0.3
>>> hostkarma.junkemailfilter.com=127.0.0.[2;4]*2
>>> # whitelists
>>> swl.spamhaus.org*-4
>>> list.dnswl.org=127.0.[0..255].[2;3]*-1
>>> rep.mailspike.net=127.0.0.[17;18]*-1
>>> rep.mailspike.net=127.0.0.[19;20]*-2
>>> hostkarma.junkemailfilter.com=127.0.0.1*-1
>>
>> I am rewarded with
>> Nov 16 14:20:35 blueberry postfix/postscreen[18461]: warning:
>> psc_dnsbl_request: connect to private/dnsblog service: Resource
>> temporarily
>> unavailable
>> Nov 16 14:20:35 blueberry postfix/postscreen[18461]: message repeated 7
>> times: [ warning: psc_dnsbl_request: connect to private/dnsblog service:
>> Resource temporarily unavailable]
>>
>> Any idea?!
>>
>> I stopped pf, removed the postscreen_cache.db file just in case, restarted
>> pf. Still getting those messages...



-- 

Florian Piekert, PMP  flo...@floppy.org

Spargelweg 5Telephone+Fax: +49-179- 3928582
38179 Schwülper-Walle/Germany

===
Note:  this message was  send by me *only* if the  eMail message contains a
correct pgp signature corresponding to my address at  flo...@floppy.org. Do
you need my  PGP  public key? Check out http://www.floppy.org or send me an
email with  the subject "send pgp public key" to  this address of mine.Thx!





signature.asc
Description: OpenPGP digital signature

RE: regexp for allowing helo host

[L . P . H . van Belle]

Some good info to read into. 

http://rob0.nodns4.us/postscreen.html
http://blog.schaal-24.de/mail/postscreen-im-kampf-gegen-spam/?lang=en 

and ofcourse a must read: 
http://www.postfix.org/POSTSCREEN_README.html 

Greetz, 

Louis

> -Oorspronkelijk bericht-
> Van: flo...@floppy.org [mailto:owner-postfix-us...@postfix.org] Namens
> Florian Piekert
> Verzonden: woensdag 16 november 2016 14:27
> Aan: L.P.H. van Belle; postfix-users@postfix.org
> Onderwerp: Re: regexp for allowing helo host
> 
> Am 16.11.2016 um 13:59 schrieb L.P.H. van Belle:
> 
> After going from
> postscreen_dnsbl_sites =
>   zen.spamhaus.org*2,
>   bl.mailspike.net,
>   bl.spamcop.net,
>   b.barracudacentral.org,
>   swl.spamhaus.org*-2
> to
> > postscreen_dnsbl_sites =
> > b.barracudacentral.org*4
> > bad.psky.me*4
> > zen.spamhaus.org*4
> > dnsbl.cobion.com*2
> > bl.spameatingmonkey.net*2
> > fresh.spameatingmonkey.net*2
> > dnsbl.anonmails.de*2
> > dnsbl.kempt.net*1
> > dnsbl.inps.de*2
> > bl.spamcop.net*2
> > dnsbl.sorbs.net*1
> > spam.dnsbl.sorbs.net*2
> > psbl.surriel.com*2
> > bl.mailspike.net*2
> > rep.mailspike.net=127.0.0.[13;14]*1
> > bl.suomispam.net*2
> > bl.blocklist.de*2
> > ix.dnsbl.manitu.net*2
> > dnsbl-2.uceprotect.net
> > hostkarma.junkemailfilter.com=127.0.0.3
> > hostkarma.junkemailfilter.com=127.0.0.[2;4]*2
> > # whitelists
> > swl.spamhaus.org*-4
> > list.dnswl.org=127.0.[0..255].[2;3]*-1
> > rep.mailspike.net=127.0.0.[17;18]*-1
> > rep.mailspike.net=127.0.0.[19;20]*-2
> > hostkarma.junkemailfilter.com=127.0.0.1*-1
> 
> I am rewarded with
> Nov 16 14:20:35 blueberry postfix/postscreen[18461]: warning:
> psc_dnsbl_request: connect to private/dnsblog service: Resource
> temporarily
> unavailable
> Nov 16 14:20:35 blueberry postfix/postscreen[18461]: message repeated 7
> times: [ warning: psc_dnsbl_request: connect to private/dnsblog service:
> Resource temporarily unavailable]
> 
> Any idea?!
> 
> I stopped pf, removed the postscreen_cache.db file just in case, restarted
> pf. Still getting those messages...
> 
> --
> 
> Florian Piekert, PMP
> flo...@floppy.org
> 
> Spargelweg 5Telephone+Fax: +49-179-
> 3928582
> 38179 Schwülper-Walle/Germany
> 
> ==
> =
> Note:  this message was  send by me *only* if the  eMail message contains
> a
> correct pgp signature corresponding to my address at  flo...@floppy.org.
> Do
> you need my  PGP  public key? Check out http://www.floppy.org or send me
> an
> email with  the subject "send pgp public key" to  this address of
> mine.Thx!

RE: regexp for allowing helo host

[L . P . H . van Belle]

Ah yes, 

In master.cf  adust these. 

smtp  inet  n   -   -   -   1   postscreen
smtpd pass  -   -   -   -   -   smtpd
dnsblog   unix  -   -   -   -   0   dnsblog



> -Oorspronkelijk bericht-
> Van: flo...@floppy.org [mailto:owner-postfix-us...@postfix.org] Namens
> Florian Piekert
> Verzonden: woensdag 16 november 2016 14:27
> Aan: L.P.H. van Belle; postfix-users@postfix.org
> Onderwerp: Re: regexp for allowing helo host
> 
> Am 16.11.2016 um 13:59 schrieb L.P.H. van Belle:
> 
> After going from
> postscreen_dnsbl_sites =
>   zen.spamhaus.org*2,
>   bl.mailspike.net,
>   bl.spamcop.net,
>   b.barracudacentral.org,
>   swl.spamhaus.org*-2
> to
> > postscreen_dnsbl_sites =
> > b.barracudacentral.org*4
> > bad.psky.me*4
> > zen.spamhaus.org*4
> > dnsbl.cobion.com*2
> > bl.spameatingmonkey.net*2
> > fresh.spameatingmonkey.net*2
> > dnsbl.anonmails.de*2
> > dnsbl.kempt.net*1
> > dnsbl.inps.de*2
> > bl.spamcop.net*2
> > dnsbl.sorbs.net*1
> > spam.dnsbl.sorbs.net*2
> > psbl.surriel.com*2
> > bl.mailspike.net*2
> > rep.mailspike.net=127.0.0.[13;14]*1
> > bl.suomispam.net*2
> > bl.blocklist.de*2
> > ix.dnsbl.manitu.net*2
> > dnsbl-2.uceprotect.net
> > hostkarma.junkemailfilter.com=127.0.0.3
> > hostkarma.junkemailfilter.com=127.0.0.[2;4]*2
> > # whitelists
> > swl.spamhaus.org*-4
> > list.dnswl.org=127.0.[0..255].[2;3]*-1
> > rep.mailspike.net=127.0.0.[17;18]*-1
> > rep.mailspike.net=127.0.0.[19;20]*-2
> > hostkarma.junkemailfilter.com=127.0.0.1*-1
> 
> I am rewarded with
> Nov 16 14:20:35 blueberry postfix/postscreen[18461]: warning:
> psc_dnsbl_request: connect to private/dnsblog service: Resource
> temporarily
> unavailable
> Nov 16 14:20:35 blueberry postfix/postscreen[18461]: message repeated 7
> times: [ warning: psc_dnsbl_request: connect to private/dnsblog service:
> Resource temporarily unavailable]
> 
> Any idea?!
> 
> I stopped pf, removed the postscreen_cache.db file just in case, restarted
> pf. Still getting those messages...
> 
> --
> 
> Florian Piekert, PMP
> flo...@floppy.org
> 
> Spargelweg 5Telephone+Fax: +49-179-
> 3928582
> 38179 Schwülper-Walle/Germany
> 
> ==
> =
> Note:  this message was  send by me *only* if the  eMail message contains
> a
> correct pgp signature corresponding to my address at  flo...@floppy.org.
> Do
> you need my  PGP  public key? Check out http://www.floppy.org or send me
> an
> email with  the subject "send pgp public key" to  this address of
> mine.Thx!

Re: regexp for allowing helo host

[Florian Piekert]

Am 16.11.2016 um 13:59 schrieb L.P.H. van Belle:

After going from
postscreen_dnsbl_sites =
  zen.spamhaus.org*2,
  bl.mailspike.net,
  bl.spamcop.net,
  b.barracudacentral.org,
  swl.spamhaus.org*-2
to
> postscreen_dnsbl_sites =
> b.barracudacentral.org*4
> bad.psky.me*4
> zen.spamhaus.org*4
> dnsbl.cobion.com*2
> bl.spameatingmonkey.net*2
> fresh.spameatingmonkey.net*2
> dnsbl.anonmails.de*2
> dnsbl.kempt.net*1
> dnsbl.inps.de*2
> bl.spamcop.net*2
> dnsbl.sorbs.net*1
> spam.dnsbl.sorbs.net*2
> psbl.surriel.com*2
> bl.mailspike.net*2
> rep.mailspike.net=127.0.0.[13;14]*1
> bl.suomispam.net*2
> bl.blocklist.de*2
> ix.dnsbl.manitu.net*2
> dnsbl-2.uceprotect.net
> hostkarma.junkemailfilter.com=127.0.0.3
> hostkarma.junkemailfilter.com=127.0.0.[2;4]*2
> # whitelists
> swl.spamhaus.org*-4
> list.dnswl.org=127.0.[0..255].[2;3]*-1
> rep.mailspike.net=127.0.0.[17;18]*-1
> rep.mailspike.net=127.0.0.[19;20]*-2
> hostkarma.junkemailfilter.com=127.0.0.1*-1

I am rewarded with
Nov 16 14:20:35 blueberry postfix/postscreen[18461]: warning:
psc_dnsbl_request: connect to private/dnsblog service: Resource temporarily
unavailable
Nov 16 14:20:35 blueberry postfix/postscreen[18461]: message repeated 7
times: [ warning: psc_dnsbl_request: connect to private/dnsblog service:
Resource temporarily unavailable]

Any idea?!

I stopped pf, removed the postscreen_cache.db file just in case, restarted
pf. Still getting those messages...

-- 

Florian Piekert, PMP  flo...@floppy.org

Spargelweg 5Telephone+Fax: +49-179- 3928582
38179 Schwülper-Walle/Germany

===
Note:  this message was  send by me *only* if the  eMail message contains a
correct pgp signature corresponding to my address at  flo...@floppy.org. Do
you need my  PGP  public key? Check out http://www.floppy.org or send me an
email with  the subject "send pgp public key" to  this address of mine.Thx!



signature.asc
Description: OpenPGP digital signature

Re: Load balance outgoing message

[Paweł Grzesik]

Not sure about the postfix but for sure you can use "haproxy".
It might be more easy to maintain it then.

Thanks,
Pawel

2016-11-16 11:27 GMT+00:00 Marcelo Machado :

> Hi everybody.
>
> Is possible with postfix send messages to multiple smart hosts randomly
> from a single domain?
>
> Marcelo Gomes
>

"mail forwarding loop" when Resending Email to Oneself.

[Ralph Corderoy]

Hi,

I send myself a little email.

Return-Path: 
X-Original-To: ralph
Delivered-To: ra...@inputplus.co.uk
Received: by orac.inputplus.co.uk (Postfix, from userid 1000)
id 9687C279FC; Wed, 16 Nov 2016 12:29:46 + (GMT)
Date: Wed, 16 Nov 2016 12:29:46 +
To: ra...@inputplus.co.uk
Message-Id: <20161116122946.9687c27...@orac.inputplus.co.uk>
From: ra...@inputplus.co.uk (Ralph Corderoy)

foo

I use nmh's dist(1) command to distribute it, using Resent-From,
Resent-To, etc., headers.  (IIRC this is similar to mutt's "bounce"
command.)

Postfix complains of a "mail forwarding loop" by return.

Return-Path: <>
X-Original-To: ra...@inputplus.co.uk
Delivered-To: ra...@inputplus.co.uk
Received: by orac.inputplus.co.uk (Postfix)
id 2DF9D27E4C; Wed, 16 Nov 2016 12:29:55 + (GMT)
Date: Wed, 16 Nov 2016 12:29:55 + (GMT)
From: mailer-dae...@inputplus.co.uk (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: ra...@inputplus.co.uk
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="0F24A1F958.1479299395/orac.inputplus.co.uk"
Content-Transfer-Encoding: 8bit
Message-Id: <20161116122955.2df9d27...@orac.inputplus.co.uk>

This is a MIME-encapsulated message.

--0F24A1F958.1479299395/orac.inputplus.co.uk
Content-Description: Notification
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

This is the mail system at host orac.inputplus.co.uk.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

 (expanded from ): mail forwarding loop for
ra...@inputplus.co.uk

--0F24A1F958.1479299395/orac.inputplus.co.uk
Content-Description: Delivery report
Content-Type: message/delivery-status
Content-Transfer-Encoding: 8bit

Reporting-MTA: dns; orac.inputplus.co.uk
X-Postfix-Queue-ID: 0F24A1F958
X-Postfix-Sender: rfc822; ra...@inputplus.co.uk
Arrival-Date: Wed, 16 Nov 2016 12:29:55 + (GMT)

Final-Recipient: rfc822; ra...@inputplus.co.uk
Original-Recipient: rfc822;ralph
Action: failed
Status: 5.4.6
Diagnostic-Code: X-Postfix; mail forwarding loop for ra...@inputplus.co.uk

--0F24A1F958.1479299395/orac.inputplus.co.uk
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

Return-Path: 
Received: from orac.inputplus.co.uk (orac.inputplus.co.uk [IPv6:::1])
by orac.inputplus.co.uk (Postfix) with ESMTP id 0F24A1F958
for ; Wed, 16 Nov 2016 12:29:55 + (GMT)
X-Original-To: ralph
Delivered-To: ra...@inputplus.co.uk
Received: by orac.inputplus.co.uk (Postfix, from userid 1000)
id 9687C279FC; Wed, 16 Nov 2016 12:29:46 + (GMT)
Date: Wed, 16 Nov 2016 12:29:46 +
To: ra...@inputplus.co.uk
User-Agent: mail v14.8.14
Message-Id: <20161116122946.9687c27...@orac.inputplus.co.uk>
From: ra...@inputplus.co.uk (Ralph Corderoy)
Resent-From: Ralph Corderoy 
Resent-To: ra...@inputplus.co.uk
Resent-Date: Wed, 16 Nov 2016 12:29:55 +
Resent-Message-Id: <20161116122955.0f24a1f...@orac.inputplus.co.uk>

foo

--0F24A1F958.1479299395/orac.inputplus.co.uk--

AIUI this is because the original email's Delivered-To header is in the
resent email with the same email address as the new email's destination.

Does an RFC cover Delivered-To?  If not, what's the closest to a
specification?

Resending the email to myself at the same email address is legitimate
and used to work in years past.  What does Postfix think an MUA should
do in this circumstance?  Remove the Delivered-To header whenever
resending?

Any other advice Postfix can offer this MUA?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

Re: regexp for allowing helo host

[Tanstaafl]

On 11/15/2016 6:11 PM, Bill Cole
 wrote:
> Be aware that if you use reject_unknown_helo_hostname you will have a 
> steady stream of cases for which  you will have to make special 
> exceptions. How steady that stream is depends more on your volume and 
> diversity of legitimate mail than on how heavily spammed you are.

What Bill is saying here is using reject_unknown_helo_hostname to
outright reject clients will reject legitimate clients, so unless you
have a good reason for doing so and know what you are doing and are
prepared to handle issues like you are experiencing now, or don't do it.

Load balance outgoing message

[Marcelo Machado]

Hi everybody.

Is possible with postfix send messages to multiple smart hosts randomly
from a single domain?

Marcelo Gomes

Re: hacker or server problem

[lists]

The full cidr is blocked in the firewall. 


  Original Message  
From: Patrick Chemla
Sent: Wednesday, November 16, 2016 2:48 AM
To: postfix-users@postfix.org
Subject: Re: hacker or server problem

Le 16/11/2016 à 12:38, li...@lazygranch.com a écrit :
> On Wed, 16 Nov 2016 02:26:13 -0800
> "li...@lazygranch.com"  wrote:
>
>> On Wed, 16 Nov 2016 11:52:14 +0200
>> Patrick Chemla  wrote:
>>
>>> Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :
 Is this a hack or a server problem. IP was listed in abusedb
 about a year ago.

 
 Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from
 unknown[87.236.215.11] Nov 16 09:14:36 theranch
 postfix/smtpd[6094]: lost connection after AUTH from
 unknown[87.236.215.11] Nov 16 09:14:36 theranch
> 
> # bzgrep -e 87.236.215.11 maillog | wc -l
> 212
>
> Three lines per hack. Make that 70 attempts. The stats line messes up
> the line count.
> First entry:Nov 16 09:13:45
> Last entry: Nov 16 09:18:00
> 255 seconds
> 16.5 attempts a minute
>
16 Attempts per second, yes this is a hack attempt.

Protect yourself immediatly, even if he will surely need some (hundred 
of) thousands attempts to find a password.

Another problem is that he is taking your bandwith.

Patrick

Re: hacker or server problem

[Patrick Chemla]

Le 16/11/2016 à 12:38, li...@lazygranch.com a écrit :

On Wed, 16 Nov 2016 02:26:13 -0800
"li...@lazygranch.com"  wrote:


On Wed, 16 Nov 2016 11:52:14 +0200
Patrick Chemla  wrote:


Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :

Is this a hack or a server problem. IP was listed in abusedb
about a year ago.


Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from
unknown[87.236.215.11] Nov 16 09:14:36 theranch
postfix/smtpd[6094]: lost connection after AUTH from
unknown[87.236.215.11] Nov 16 09:14:36 theranch


# bzgrep -e 87.236.215.11 maillog | wc -l
  212

Three lines per hack. Make that 70 attempts. The stats line messes up
the line count.
First entry:Nov 16 09:13:45
Last entry: Nov 16 09:18:00
255 seconds
16.5 attempts a minute


16 Attempts per second, yes this is a hack attempt.

Protect yourself immediatly, even if he will surely need some (hundred 
of) thousands attempts to find a password.


Another problem is that he is taking your bandwith.

Patrick

Re: hacker or server problem

[li...@lazygranch.com]

On Wed, 16 Nov 2016 02:26:13 -0800
"li...@lazygranch.com"  wrote:

> On Wed, 16 Nov 2016 11:52:14 +0200
> Patrick Chemla  wrote:
> 
> > Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :  
> > > Is this a hack or a server problem. IP was listed in abusedb
> > > about a year ago.
> > >
> > > 
> > > Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from
> > > unknown[87.236.215.11] Nov 16 09:14:36 theranch
> > > postfix/smtpd[6094]: lost connection after AUTH from
> > > unknown[87.236.215.11] Nov 16 09:14:36 theranch

 
> 
# bzgrep -e 87.236.215.11 maillog | wc -l
 212

Three lines per hack. Make that 70 attempts. The stats line messes up
the line count.
First entry:Nov 16 09:13:45 
Last entry: Nov 16 09:18:00
255 seconds
16.5 attempts a minute

Re: hacker or server problem

[li...@lazygranch.com]

On Wed, 16 Nov 2016 11:52:14 +0200
Patrick Chemla  wrote:

> Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :
> > Is this a hack or a server problem. IP was listed in abusedb about a
> > year ago.
> >
> > 
> > Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from
> > unknown[87.236.215.11] Nov 16 09:14:36 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:36 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:36 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:37 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:37 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:37 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:38 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:38 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:38 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:39 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:39 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:39 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:39 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:39 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:40 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:40 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:40 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:18:00 theranch postfix/anvil[6096]:
> > statistics: max connection rate 70/60s for (smtp:87.236.215.11) at
> > Nov 16 09:14:40 Nov 16 09:18:00 theranch postfix/anvil[6096]:
> > statistics: max connection count 1 for (smtp:87.236.215.11) at Nov
> > 16 09:13:45 Nov 16 09:18:00 theranch postfix/anvil[6096]:
> > statistics: max cache size 1 at Nov 16 09:13:45  
> 
> Hi,
> 
> This is a trace of 6 connections tries from IP 87.236.215.11 with bad 
> credential (user/passwd).
> 
> Someone is trying to enter your server emails. Call it a hack.
> 
> Patrick
> 
> www.top-secured.com
> 

Actually way more than 6 attempts. I made a quick and dirty edit to the
firewall and blocked the entire CIDR 87.236.215.0/24

I don't see any usernames/domains in the log file, thus my confusion
about if it is a hack or a whacked out server. Now this is something I
could see setting up fail2ban to block. 

Re: hacker or server problem

[Patrick Chemla]

Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :

Is this a hack or a server problem. IP was listed in abusedb about a
year ago.


Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:36 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:36 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:37 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:37 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:37 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:38 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:38 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:38 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:39 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:40 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:40 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:40 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max connection rate 
70/60s for (smtp:87.236.215.11) at Nov 16 09:14:40
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max connection count 
1 for (smtp:87.236.215.11) at Nov 16 09:13:45
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max cache size 1 at 
Nov 16 09:13:45


Hi,

This is a trace of 6 connections tries from IP 87.236.215.11 with bad 
credential (user/passwd).


Someone is trying to enter your server emails. Call it a hack.

Patrick

www.top-secured.com

hacker or server problem

[li...@lazygranch.com]

Is this a hack or a server problem. IP was listed in abusedb about a
year ago.


Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:36 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:36 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:37 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:37 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:37 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:38 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:38 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:38 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:39 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:40 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:40 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:40 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max connection rate 
70/60s for (smtp:87.236.215.11) at Nov 16 09:14:40
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max connection count 
1 for (smtp:87.236.215.11) at Nov 16 09:13:45
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max cache size 1 at 
Nov 16 09:13:45