Re: Open relay

2016-10-21 Thread Bill Cole

On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:


Hello,

I have a big problem, someone is using my mailserver for sending spam. 
I

see it in de logs. I can block the IP but then they use other IP's.

So far I know my server is up-to-date and correct configured. And when 
I

do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx

The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.

What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not 
help.

All spam is recognizeble by this authenticated username.

In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):

Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi 
[87.92.55.206])

(Authenticated sender: p...@puk.nl)
by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

As would my server sent it to my server...


Not exactly. That Received header indicates that the machine at 
87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi 
introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
proceeded to authenticate as the user whose name you've replaced with  
p...@puk.nl.


As a stopgap, you could add a directive like this to 
smtpd_helo_restrictions:


   check_helo_access pcre:/etc/postfix/helo_checks

And in that helo_checks file;

/127\.0\.0\.1/  REJECT you are not me


This will catch and reject formally correct IP literals as in this case 
and the more common bare IP form of claiming to be localhost. There's no 
reason for any mail client ever to say "EHLO [127.0.0.1]" except to 
cause a MTA to generate a confusing Received header.



Does somebody have a clou here?

With regards,
Paul van der Vlis.

Some settings and logs:


Those are inadequate to understand this problem.

See the bottom part of the Postfix DEBUG_README file, probably installed 
on your machine with Postfix (maybe in both plaintext and HTML) and 
always available on the Postfix website. It describes what information 
is needed to effectively get help here. The welcome message you got when 
you subscribed this list also referenced that document.


Paraphrasing the DEBUG_README and adapting its recommendations to this 
issue, you should include:


Full 'postconf -nf' output
Full 'postconf -Mf' output
Full headers of a sample spam message, redacted only to protect *USER* 
privacy. (Don't redact hostnames or IPs)
All log lines containing the Postfix queue id of the sample spam 
message.
If your SASL layer logs authentication successes and failures (perhaps 
in /var/log/auth.log) find the relevant log entries for the sample 
message.


There is no need for verbose logging by Postfix.


Re: How to limit max trying helo or ehlo times to mail server?

2016-10-21 Thread vod vos
OK, I found 
http://www.postfix.org/postconf.5.html#smtpd_client_connection_count_limit



The default value is 50.



So it seems no need to modify anything after reading Noel Jones's analyzation.



Thanks.




 On 星期五, 21 十月 2016 11:51:50 -0700Noel Jones njo...@megan.vbhcs.org 
wrote 




On 10/21/2016 1:13 PM, vod vos wrote: 

 Hi guys, 

 

 When I reviewed the mail.log, it showed a IP was trying to test if 

 relay was open or not. However, the times were too many. 

 

 * 

 What is the max limited times of postfix defaultly defined? 

 

 

See the STRESS_README document. 

http://www.postfix.org/STRESS_README.html 

 

 

 

 * 

 And how to modify it or how to set helo/ehlo restriction? 

 

 

 Thanks. 

 

 Here is the log: 

 

Many unrelated entries snipped. 

 

 

 

 

 Oct 19 22:21:34 mail postfix/smtpd[1796]: connect from 

 unknown[61.145.214.178] 

 

client connects. 

 

 

 Oct 19 22:21:42 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 

 unknown[61.145.214.178]: 554 5.7.1 xiaonanzi11...@vip.126.com: 

 Relay access denied; from=q...@example.com 

 to=xiaonanzi11...@vip.126.com proto=ESMTP 
helo=XL-20160621FCVQ 

 

Client attempts unauthorized relay, postfix rejects it. 

 

 

 

 Oct 19 22:21:42 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 

 unknown[61.145.214.178]: 554 5.7.1 xiaonanzi11...@vip.126.com: 

 Relay access denied; from=q...@example.com 

 to=xiaonanzi11...@vip.126.com proto=ESMTP 
helo=XL-20160621FCVQ 

 

(other Relay attempts snipped) 

 

 

 Oct 19 22:22:05 mail postfix/smtpd[1796]: improper command 

 pipelining after DATA from unknown[61.145.214.178]: 

 

client talks out of turn, then tries some more unauthorized relays. 

... 

 

 Oct 19 22:22:29 mail postfix/smtpd[1796]: too many errors after DATA from 
unknown[61.145.214.178] 

 

postfix hangs up on the bad client. 

 

 

 

 Oct 19 22:22:29 mail postfix/smtpd[1796]: disconnect from 
unknown[61.145.214.178] ehlo=1 mail=10 rcpt=0/10 data=0/10 rset=10 
commands=21/41 

 

Client tried 10 recipients, 0 were accepted; all were unauthorized 

relay attempts. After the 10th attempt, postfix disconnected. 

 

 

Looks as if postfix is working just fine. Nothing more to do here. 

 

 

 

 -- Noel Jones 








Re: Open relay

2016-10-21 Thread Wietse Venema
Paul van der Vlis:
> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
> (Authenticated sender: p...@puk.nl)
> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

That is NOT RELAYING. That is receiving mail from a process that
runs on the same machine. This can happen when the machine runs a
bad web application.

Wietse


Re: Open relay

2016-10-21 Thread li...@lazygranch.com
On Fri, 21 Oct 2016 22:56:45 +0200
Paul van der Vlis  wrote:

> Hello Angelo and others,
> 
> Op 21-10-16 om 22:24 schreef Fazzina, Angelo:
> > So what is SASL using in Postfix ?
> > Is Postfix calling SASL, which calls PAM, which calls LDAP, to
> > check the Password?
> 
> Postfix is calling saslauthd, which calls PAM, which calls unix
> passwords.
> 
> > You must follow the trail of how they got the password if you say
> > you changed it and it does not help.
> 
> I don't think they have a correct username/password combination,
> because the username is wrong.
> 
> Maybe it's possible to log the username/password Postfix get?
> 
> Maybe they are using some kind of trick to let Postfix think the mail
> comes from localhost.
> 
> With regards,
> Paul van der Vlis.
> 
> 
> > -ALF
> > 
> > -Angelo Fazzina
> > Operating Systems Programmer / Analyst 
> > University of Connecticut,  UITS, SSG-Linux/ M
> > 860-486-9075
> > 
> > -Original Message-
> > From: owner-postfix-us...@postfix.org
> > [mailto:owner-postfix-us...@postfix.org] On Behalf Of Paul van der
> > Vlis Sent: Friday, October 21, 2016 4:16 PM To:
> > postfix-users@postfix.org Subject: Open relay
> > 
> > Hello,
> > 
> > I have a big problem, someone is using my mailserver for sending
> > spam. I see it in de logs. I can block the IP but then they use
> > other IP's.
> > 
> > So far I know my server is up-to-date and correct configured. And
> > when I do some open relay tests, everything is OK. Like this ones:
> > http://www.mailradar.com/openrelay/
> > http://mxtoolbox.com/diagnostic.aspx
> > 
> > The name of my mailserver is mail.vandervlis.nl, so far I see the
> > spammers are using port 587. Please feel free to do tests.
> > 
> > What I see in the logs and in the headers of the spam is that they
> > are using authentication. But the username is not correct. On my
> > server I use usernames like "john", and this username lookslike an
> > e-mail address, so with an "@" in it. The part before the @ is a
> > correct username on my server, but when I change the password it
> > does not help. All spam is recognizeble by this authenticated
> > username.
> > 
> > In the headers I see this as the first "received" (I've changed the
> > authenticated sender for privacy):
> > 
> > Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> > [87.92.55.206]) (Authenticated sender: p...@puk.nl)
> > by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> > Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> > 
> > As would my server sent it to my server...
> > 
> > Does somebody have a clou here?
> > 
> > With regards,
> > Paul van der Vlis.
> > 
> > 
> > Some settings and logs:
> > 
> > smtpd_relay_restrictions =
> >   permit_mynetworks,
> >   permit_sasl_authenticated,
> >   check_sender_access hash:/etc/postfix/whitelist,
> >   reject_invalid_hostname,
> >   reject_non_fqdn_sender,
> >   reject_non_fqdn_recipient,
> >   reject_unknown_sender_domain,
> >   reject_unknown_recipient_domain,
> >   reject_unauth_pipelining,
> >   reject_unauth_destination,
> >   check_policy_service unix:private/shadelist,
> >   reject_rbl_client bl.spamcop.net,
> >   reject_rbl_client zen.spamhaus.org,
> >   reject_rbl_client ix.dnsbl.manitu.net,
> >   permit
> > 
> > smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
> > smtpd_use_tls = yes
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_exceptions_networks = $mynetworks
> > smtpd_tls_loglevel = 1
> > smtpd_tls_auth_only = yes
> > smtpd_sasl_security_options = noanonymous
> > smtpd_sasl_tls_security_options = noanonymous
> > broken_sasl_auth_clients = yes
> > smtpd_sasl_authenticated_header = yes
> > 
> > Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
> > client=unknown[94.26.41.188], sasl_method=PLAIN,
> > sasl_username=p...@puk.nl
> > 
> > 
> 
> 
> 

Perhaps I'm being a bit anal here, and given my skill level (or lack
thereof) I should stay of of this, but is this actually an open relay in
the strict sense? Maybe that is a red herring. If they are using 587,
that would be the master.cf file, not main.cf.

submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
 


Re: Problem with ldap failover

2016-10-21 Thread A. Schulze


Am 21.10.2016 um 13:49 schrieb MichalZ:
> server_host =   ldaps://ldap3.img.local:636
> ldaps://ldap2.img.local:636
> ldaps://ldap.img.local:636

did you check that every single server work without the others?

try1: server_host = ldaps://ldap3.img.local:636
try2: server_host = ldaps://ldap2.img.local:636
try3: server_host = ldaps://ldap.img.local:636




Re: Open relay

2016-10-21 Thread Paul van der Vlis
Hello Angelo and others,

Op 21-10-16 om 22:24 schreef Fazzina, Angelo:
> So what is SASL using in Postfix ?
> Is Postfix calling SASL, which calls PAM, which calls LDAP, to check the 
> Password?

Postfix is calling saslauthd, which calls PAM, which calls unix passwords.

> You must follow the trail of how they got the password if you say you changed 
> it and it does not help.

I don't think they have a correct username/password combination, because
the username is wrong.

Maybe it's possible to log the username/password Postfix get?

Maybe they are using some kind of trick to let Postfix think the mail
comes from localhost.

With regards,
Paul van der Vlis.


> -ALF
> 
> -Angelo Fazzina
> Operating Systems Programmer / Analyst 
> University of Connecticut,  UITS, SSG-Linux/ M
> 860-486-9075
> 
> -Original Message-
> From: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Paul van der Vlis
> Sent: Friday, October 21, 2016 4:16 PM
> To: postfix-users@postfix.org
> Subject: Open relay
> 
> Hello,
> 
> I have a big problem, someone is using my mailserver for sending spam. I
> see it in de logs. I can block the IP but then they use other IP's.
> 
> So far I know my server is up-to-date and correct configured. And when I
> do some open relay tests, everything is OK. Like this ones:
> http://www.mailradar.com/openrelay/
> http://mxtoolbox.com/diagnostic.aspx
> 
> The name of my mailserver is mail.vandervlis.nl, so far I see the
> spammers are using port 587. Please feel free to do tests.
> 
> What I see in the logs and in the headers of the spam is that they are
> using authentication. But the username is not correct. On my server I
> use usernames like "john", and this username lookslike an e-mail
> address, so with an "@" in it. The part before the @ is a correct
> username on my server, but when I change the password it does not help.
> All spam is recognizeble by this authenticated username.
> 
> In the headers I see this as the first "received" (I've changed the
> authenticated sender for privacy):
> 
> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
> (Authenticated sender: p...@puk.nl)
> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> 
> As would my server sent it to my server...
> 
> Does somebody have a clou here?
> 
> With regards,
> Paul van der Vlis.
> 
> 
> Some settings and logs:
> 
> smtpd_relay_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   check_sender_access hash:/etc/postfix/whitelist,
>   reject_invalid_hostname,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_unauth_pipelining,
>   reject_unauth_destination,
>   check_policy_service unix:private/shadelist,
>   reject_rbl_client bl.spamcop.net,
>   reject_rbl_client zen.spamhaus.org,
>   reject_rbl_client ix.dnsbl.manitu.net,
>   permit
> 
> smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
> smtpd_use_tls = yes
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_exceptions_networks = $mynetworks
> smtpd_tls_loglevel = 1
> smtpd_tls_auth_only = yes
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_tls_security_options = noanonymous
> broken_sasl_auth_clients = yes
> smtpd_sasl_authenticated_header = yes
> 
> Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
> client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=p...@puk.nl
> 
> 



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/


RE: Open relay

2016-10-21 Thread Fazzina, Angelo
So what is SASL using in Postfix ?
Is Postfix calling SASL, which calls PAM, which calls LDAP, to check the 
Password?


You must follow the trail of how they got the password if you say you changed 
it and it does not help.
-ALF

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

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Paul van der Vlis
Sent: Friday, October 21, 2016 4:16 PM
To: postfix-users@postfix.org
Subject: Open relay

Hello,

I have a big problem, someone is using my mailserver for sending spam. I
see it in de logs. I can block the IP but then they use other IP's.

So far I know my server is up-to-date and correct configured. And when I
do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx

The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.

What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not help.
All spam is recognizeble by this authenticated username.

In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):

Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
(Authenticated sender: p...@puk.nl)
by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

As would my server sent it to my server...

Does somebody have a clou here?

With regards,
Paul van der Vlis.


Some settings and logs:

smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_sender_access hash:/etc/postfix/whitelist,
  reject_invalid_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  check_policy_service unix:private/shadelist,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  permit

smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_use_tls = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes

Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=p...@puk.nl


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/


Open relay

2016-10-21 Thread Paul van der Vlis
Hello,

I have a big problem, someone is using my mailserver for sending spam. I
see it in de logs. I can block the IP but then they use other IP's.

So far I know my server is up-to-date and correct configured. And when I
do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx

The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.

What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not help.
All spam is recognizeble by this authenticated username.

In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):

Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
(Authenticated sender: p...@puk.nl)
by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

As would my server sent it to my server...

Does somebody have a clou here?

With regards,
Paul van der Vlis.


Some settings and logs:

smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_sender_access hash:/etc/postfix/whitelist,
  reject_invalid_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  check_policy_service unix:private/shadelist,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  permit

smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_use_tls = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes

Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=p...@puk.nl


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/


Re: How to limit max trying helo or ehlo times to mail server?

2016-10-21 Thread Noel Jones
On 10/21/2016 1:13 PM, vod vos wrote:
> Hi guys,
> 
> When I reviewed the mail.log, it showed a IP was trying to test if
> relay was open or not. However, the times were too many.
> 
>   *
> What is the max limited times of postfix defaultly defined?
> 

See the STRESS_README document.
http://www.postfix.org/STRESS_README.html


> 
>   *
> And how to modify it or how to set helo/ehlo restriction?
> 
> 
> Thanks.
> 
> Here is the log:

Many unrelated entries snipped.



> 
> Oct 19 22:21:34 mail postfix/smtpd[1796]: connect from
> unknown[61.145.214.178]

client connects.


> Oct 19 22:21:42 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from
> unknown[61.145.214.178]: 554 5.7.1 :
> Relay access denied; from=
> to= proto=ESMTP helo=

Client attempts unauthorized relay, postfix rejects it.

> 
> 
> Oct 19 22:21:42 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from
> unknown[61.145.214.178]: 554 5.7.1 :
> Relay access denied; from=
> to= proto=ESMTP helo=

(other Relay attempts snipped)

> 
> Oct 19 22:22:05 mail postfix/smtpd[1796]: improper command
> pipelining after DATA from unknown[61.145.214.178]:

client talks out of turn, then tries some more unauthorized relays.
...

> Oct 19 22:22:29 mail postfix/smtpd[1796]: too many errors after DATA from 
> unknown[61.145.214.178]

postfix hangs up on the bad client.

> 
> 
> Oct 19 22:22:29 mail postfix/smtpd[1796]: disconnect from 
> unknown[61.145.214.178] ehlo=1 mail=10 rcpt=0/10 data=0/10 rset=10 
> commands=21/41

Client tried 10 recipients, 0 were accepted;  all were unauthorized
relay attempts.  After the 10th attempt, postfix disconnected.


Looks as if postfix is working just fine.  Nothing more to do here.



  -- Noel Jones


Re: How to limit max trying helo or ehlo times to mail server?

2016-10-21 Thread Wietse Venema
vod vos:
> Hi guys,
>
> When I reviewed the mail.log, it showed a IP was trying to test
> if relay was open or not. However, the times were too many.
>
> What is the max limited times of postfix defaultly defined?

$ postconf | grep '^smtpd_client.*limit'

WEietse


Re: From in Body mail

2016-10-21 Thread Noel Jones
On 10/21/2016 10:41 AM, Paweł Grzesik wrote:
>> DATA
>> 354 End data with .
>> From: j...@mailtest.example.com
>   >
>> To: pa...@mailtest.example.com
>   >
>> Subject: Testing SCAM
>> Text: ABC123
>> .
>> 250 2.0.0 Ok: queued as 481D6C76B6
> 
> But I'm talking about this part. So here we have DATA where I can
> type From:, To: and Subject: then message and e-mail will go
> from the "From:" instead of the one from the header "MAIL FROM:".
> 
> The problem is that most of the e-mail clients will show that From
> in the From. I'm not sure if there is a way to block it? Or I'm
> missing something?

Yes, most *mail clients* will display the From: header rather than
the envelope sender.  Additionally, if you reply to the message, the
*mail client* will reply to the From: header rather than the
envelope sender.

First note different envelope sender and From: header isn't a
postfix issue; it's how email is designed to work.

Next note that it's the mail client that chooses to display the
From: header rather than the envelope sender; this is the accepted
behavior across virtually all mail clients.  Nothing prevents the
mail client from displaying the envelope sender (usually found in
the Return-Path: pseudo-header after delivery), but few (none?) of
them chose to do so. Probably because most end users would find it
confusing.

That's how email works, and it's a useful feature used by mailing
lists, remailers, automated notification systems, etc.  Yes,
unfortunately some abuse this feature.  If we disable every feature
that might be abused, we're left with nothing.





  -- Noel Jones


How to limit max trying helo or ehlo times to mail server?

2016-10-21 Thread vod vos
Hi guys,



When I reviewed the mail.log, it showed a IP was trying to test if relay was 
open or not. However, the times were too many. 



What is the max limited times of postfix defaultly defined? 




And how to modify it or how to set helo/ehlo restriction? 




Thanks.



Here is the log:



Oct 19 22:21:34 mail postfix/smtpd[1796]: connect from unknown[61.145.214.178]



Oct 19 22:21:39 mail postfix/verify[1801]: cache 
btree:/var/lib/postfix/verify_cache full cleanup: retained=14 dropped=0 entries



Oct 19 22:21:39 mail postfix/cleanup[1802]: 90B463E999: 
mailage-id=20161019142139.90b463e...@mail.example.com



Oct 19 22:21:39 mail postfix/qmgr[1610]: 90B463E999: 
from=double-bou...@example.com, size=266, nrcpt=1 (queue active)



Oct 19 22:21:39 mail postfix/local[1803]: 90B463E999: 
to=q...@example.com, relay=local, delay=0.01, delays=0/0.01/0/0, 
dsn=5.1.1, status=undeliverable (unknown user: "quae")



Oct 19 22:21:39 mail postfix/qmgr[1610]: 90B463E999: removed



Oct 19 22:21:42 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 xiaonanzi11...@vip.126.com: Relay 
access denied; from=q...@example.com 
to=xiaonanzi11...@vip.126.com proto=ESMTP helo=XL-20160621FCVQ



Oct 19 22:21:42 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 xiaonanzi11...@vip.126.com: Relay 
access denied; from=q...@example.com 
to=xiaonanzi11...@vip.126.com proto=ESMTP helo=XL-20160621FCVQ



Oct 19 22:21:43 mail postfix/cleanup[1802]: 2D0153E999: 
mailage-id=20161019142143.2d0153e...@mail.example.com



Oct 19 22:21:43 mail postfix/qmgr[1610]: 2D0153E999: 
from=double-bou...@example.com, size=266, nrcpt=1 (queue active)



Oct 19 22:21:43 mail postfix/local[1803]: 2D0153E999: 
to=wb...@example.com, relay=local, delay=0, delays=0/0/0/0, dsn=5.1.1, 
status=undeliverable (unknown user: "wbgkp")



Oct 19 22:21:43 mail postfix/qmgr[1610]: 2D0153E999: removed



Oct 19 22:21:46 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 xiaonanzi11...@vip.126.com: Relay 
access denied; from=wb...@example.com 
to=xiaonanzi11...@vip.126.com proto=ESMTP helo=XL-20160621FCVQ



Oct 19 22:21:46 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 xiaonanzi11...@vip.126.com: Relay 
access denied; from=wb...@example.com 
to=xiaonanzi11...@vip.126.com proto=ESMTP helo=XL-20160621FCVQ



Oct 19 22:21:54 mail postfix/cleanup[1802]: 8F3E03E999: 
mailage-id=20161019142154.8f3e03e...@mail.example.com



Oct 19 22:21:54 mail postfix/qmgr[1610]: 8F3E03E999: 
from=double-bou...@example.com, size=266, nrcpt=1 (queue active)



Oct 19 22:21:54 mail postfix/local[1803]: 8F3E03E999: 
to=g...@example.com, relay=local, delay=0, delays=0/0/0/0, dsn=5.1.1, 
status=undeliverable (unknown user: "gkq")



Oct 19 22:21:54 mail postfix/qmgr[1610]: 8F3E03E999: removed



Oct 19 22:21:57 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 jijing...@163.com: Relay access 
denied; from=g...@example.com to=jijing...@163.com proto=ESMTP 
helo=XL-20160621FCVQ



Oct 19 22:22:04 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 jijing...@163.com: Relay access 
denied; from=g...@example.com to=jijing...@163.com proto=ESMTP 
helo=XL-20160621FCVQ



Oct 19 22:22:05 mail postfix/smtpd[1796]: improper command pipelining after 
DATA from unknown[61.145.214.178]:



Oct 19 22:22:08 mail postfix/cleanup[1802]: 8E51D3E999: 
mailage-id=20161019142208.8e51d3e...@mail.example.com



Oct 19 22:22:08 mail postfix/qmgr[1610]: 8E51D3E999: 
from=double-bou...@example.com, size=266, nrcpt=1 (queue active)



Oct 19 22:22:08 mail postfix/local[1803]: 8E51D3E999: 
to=xg...@example.com, relay=local, delay=0, delays=0/0/0/0, dsn=5.1.1, 
status=undeliverable (unknown user: "xgnsa")



Oct 19 22:22:08 mail postfix/qmgr[1610]: 8E51D3E999: removed



Oct 19 22:22:11 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 jijing...@163.com: Relay access 
denied; from=xg...@example.com to=jijing...@163.com proto=ESMTP 
helo=XL-20160621FCVQ



Oct 19 22:22:15 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 jijing...@163.com: Relay access 
denied; from=xg...@example.com to=jijing...@163.com proto=ESMTP 
helo=XL-20160621FCVQ



Oct 19 22:22:19 mail postfix/cleanup[1802]: 8F8A13E999: 
mailage-id=20161019142219.8f8a13e...@mail.example.com



Oct 19 22:22:19 mail postfix/qmgr[1610]: 8F8A13E999: 
from=double-bou...@example.com, size=266, nrcpt=1 (queue active)



Oct 19 22:22:19 mail postfix/local[1803]: 8F8A13E999: 
to=vb...@example.com, relay=local, delay=0, delays=0/0/0/0, dsn=5.1.1, 
status=undeliverable (unknown user: "vbfjo")



Oct 19 22:22:19 mail postfix/qmgr[1610]: 8F8A13E999: removed



Oct 19 22:22:22 mail postfix/smtpd[1796]: NOQUEUE: reject: RCPT from 
unknown[61.145.214.178]: 554 5.7.1 

Re: From in Body mail

2016-10-21 Thread Ralph Seichter
On 21.10.16 17:41, Paweł Grzesik wrote:

> So here we have DATA where I can type From:, To: and Subject: then
> message and e-mail will go from the "From:" instead of the one from
> the header "MAIL FROM:".

No. Postfix - the MTA - uses the envelope sender address (which you can
verify on the receiving server). Mail clients - MUA - display the
"From:" Header content, which can be completely different.

This is just how E-Mail works. Don't try to block it, it makes no sense
to do so. You'll definitely want to read up on this subject elsewhere,
because this is not Postfix specific.

-Ralph


Re: Postfix submission port closed

2016-10-21 Thread Davide Marchi

/dev/rob0 ha scritto:

If
you do encounter Postfix problems later, please see this link, which
was given in the list welcome message, before posting again:

http://www.postfix.org/DEBUG_README.html#mail

Many thanks.

Good bye



--
cosmogoniA
cosmogoniA
n o p r o v a r e n o f a r e o n o n f a r e n o n c e p r o v a r e


Re: From in Body mail

2016-10-21 Thread Paweł Grzesik
> DATA
> 354 End data with .
> From: j...@mailtest.example.com 
> To: pa...@mailtest.example.com 
> Subject: Testing SCAM
> Text: ABC123
> .
> 250 2.0.0 Ok: queued as 481D6C76B6

But I'm talking about this part. So here we have DATA where I can
type From:, To: and Subject: then message and e-mail will go
from the "From:" instead of the one from the header "MAIL FROM:".

The problem is that most of the e-mail clients will show that From
in the From. I'm not sure if there is a way to block it? Or I'm
missing something?

Thanks


2016-10-21 16:34 GMT+01:00 Noel Jones :

> On 10/21/2016 1:50 AM, Paweł Grzesik wrote:
> > Hi Noel,
> >
> > This is how I'm doing it:
> >
> > [user@mailtest ~]# telnet localhost 25
> > Trying 127.0.0.1...
> > Connected to localhost.
> > Escape character is '^]'.
> > 220 mailtest.example.com  ESMTP Postfix
> > HELO mailtest
> > 250 mailtest.example.com 
> > MAIL FROM: >
> > 250 2.1.0 Ok
> > RCPT TO: pa...@example.com 
> > 250 2.1.5 Ok
> > DATA
> > 354 End data with .
> > From: j...@mailtest.example.com 
> > To: pa...@mailtest.example.com 
> > Subject: Testing SCAM
> > Text: ABC123
> > .
> > 250 2.0.0 Ok: queued as 481D6C76B6
>
>
> That's a header, not the body, and is not used for anything other
> than display in your mail client.  Looks as if you've discovered
> that the From: header doesn't have any relation to the envelope
> sender.  This is a basic feature and requirement of mail.
>
>
>   -- Noel Jones
>


Re: From in Body mail

2016-10-21 Thread Noel Jones
On 10/21/2016 1:50 AM, Paweł Grzesik wrote:
> Hi Noel,
> 
> This is how I'm doing it:
> 
> [user@mailtest ~]# telnet localhost 25
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 mailtest.example.com  ESMTP Postfix
> HELO mailtest
> 250 mailtest.example.com 
> MAIL FROM: >
> 250 2.1.0 Ok
> RCPT TO: pa...@example.com 
> 250 2.1.5 Ok
> DATA
> 354 End data with .
> From: j...@mailtest.example.com 
> To: pa...@mailtest.example.com 
> Subject: Testing SCAM
> Text: ABC123
> .
> 250 2.0.0 Ok: queued as 481D6C76B6


That's a header, not the body, and is not used for anything other
than display in your mail client.  Looks as if you've discovered
that the From: header doesn't have any relation to the envelope
sender.  This is a basic feature and requirement of mail.


  -- Noel Jones


Re: preserve recipient with catchall

2016-10-21 Thread Bill Cole

On 21 Oct 2016, at 6:57, Volker Cordes wrote:


Hello,

I have a domain where all mail is stored in a single mailbox and then
being fetched by a zarafa server via pop3. The zarafa server of course
has to be able to deliver the mails to the correct users. So I tried
adding X-Envelope-To via check_recipient_access which is working as 
long

as there only is one recipient.


This is an intrinsically flawed design. The fact that it mostly works 
and has been done by many people for many years can't fix the 
misapplication of POP3 to the role of intermediate mail transport.



With mulitiple recipients (to, cc and bcc fields) for each recipient
address a X-Envelope-To header is generated and the mail is delivered
once for every recipient into the catchall mailbox. Is it possible to
change this behaviour so that there is only one X-Envelope-To header 
in

every delivered mail?


smtpd_recipient_limit=1

The primary risk of that setting is due to the fact that some SMTP 
clients do not properly handle a 4xx response to the 2nd-nth RCPTs, 
which is how Postfix enforces the policy. 99.99% of the multi-recipient 
messages will get delivered, possibly with the additional recipients 
delayed substantially, but some tiny fraction will not get retried by 
sending systems and another tiny fraction will simply fail at the first 
4xx and be retried with all recipients until the client gives up.




Re: preserve recipient with catchall

2016-10-21 Thread Wietse Venema
Volker Cordes:
> Hello,
> 
> I have a domain where all mail is stored in a single mailbox and then
> being fetched by a zarafa server via pop3. The zarafa server of course
> has to be able to deliver the mails to the correct users. So I tried
> adding X-Envelope-To via check_recipient_access which is working as long
> as there only is one recipient.

Don't set 'smtpd_delay_reject=no', and don't put that
check_recipient_access in smtpd_data_restrictions.

Wietse


Re: Using Postfix to forward mail to external accounts

2016-10-21 Thread Ralph Seichter
On 21.10.16 14:23, flemingp wrote:

> host mx1.krystal.co.uk[77.72.0.30] said: 550 Access denied - Invalid
> HELO name (See RFC5321 4.1.1.1) (in reply to RCPT TO command)
> [...]
> myhostname = raspberrypi

The server mx1.krystal.co.uk rejects your HELO. Use a fully qualified
name in 'myhostname'. https://tools.ietf.org/html/rfc5321 provides more
information.

-Ralph



Using Postfix to forward mail to external accounts

2016-10-21 Thread flemingp
As will be clear I am new to Postfix.

I am setting up a server to run a Wordpress site which is currently hosted
by a third party.

I want to use postfix to handle forwarding of email to specific.users@domain
of the website to a user@gmail account.

I found an article to do this with some simple instructions.

I have a static ip address for the proposed server xxx.xxx.xxx.yyy, the the
domain name is still in use on the hosted third party so on my test system I
am using a ip literals.

I have two problems at the moment:

1. if an email is forwarded to the gmail user account - it does not arrive
at the gmail account, with no apparent error in the postfix log as far as I
can see

2. if an email is forwarded to another p...@anoymised35.co.uk different
external account, I get an email from postfix to the usera@gmail account :


This is the mail system at host raspberrypi.

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 ): host
mx1.krystal.co.uk[77.72.0.30] said: 550 Access denied - Invalid HELO
name
(See RFC5321 4.1.1.1) (in reply to RCPT TO command)



Reporting-MTA: dns; raspberrypi
X-Postfix-Queue-ID: 510909DE68
X-Postfix-Sender: rfc822; gmail.u...@gmail.com
Arrival-Date: Tue, 18 Oct 2016 09:52:53 +0100 (BST)

Final-Recipient: rfc822; p...@anoymised35.co.uk
Original-Recipient: rfc822;p...@xxx.xxx.xxx.yy
Action: failed
Status: 5.0.0
Remote-MTA: dns; mx1.krystal.co.uk
Diagnostic-Code: smtp; 550 Access denied - Invalid HELO name (See RFC5321
4.1.1.1)


postconf -n  gives:


alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
mailbox_size_limit = 0
mydestination = [xxx.xxx.xxx.yy], xxx.xxx.xxx.yy, localhost.localdomain, ,
localhost
myhostname = raspberrypi
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
readme_directory = no
recipient_delimiter = +
relayhost =
resolve_numeric_domain = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Raspbian)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes


# See man 5 aliases for format
postmaster:root


MAILER-DAEMON: postmaster


Alias file:


# Common aliases
abuse: postmaster
spam: postmaster

# Other aliases
root:  gmail.u...@gmail.com

gerry: gmail.u...@gmail.com

paul: p...@anoymised35.co.uk


Postfix log:

Oct 18 09:52:23 raspberrypi postfix/smtpd[3061]: connect from
mail-lf0-f44.google.com[209.85.215.44]
Oct 18 09:52:23 raspberrypi postfix/smtpd[3061]: 967DA9DE67:
client=mail-lf0-f44.google.com[209.85.215.44]
Oct 18 09:52:23 raspberrypi postfix/cleanup[3065]: 967DA9DE67:
message-id=<20bcc940-d91f-f6cb-167c-a9aef5227...@gmail.com>
Oct 18 09:52:23 raspberrypi postfix/qmgr[2125]: 967DA9DE67:
from=, size=2648, nrcpt=1 (queue active)
Oct 18 09:52:23 raspberrypi postfix/cleanup[3065]: CB7159DE68:
message-id=<20bcc940-d91f-f6cb-167c-a9aef5227...@gmail.com>
Oct 18 09:52:23 raspberrypi postfix/local[3066]: 967DA9DE67:
to=, orig_to=, relay=local, delay=0.24, delays=0.22/0.02/0/0.01, dsn=2.0.0, status=sent
(forwarded as CB7159DE68)
Oct 18 09:52:23 raspberrypi postfix/qmgr[2125]: CB7159DE68:
from=, size=2776, nrcpt=1 (queue active)
Oct 18 09:52:23 raspberrypi postfix/qmgr[2125]: 967DA9DE67: removed
Oct 18 09:52:23 raspberrypi postfix/smtpd[3061]: disconnect from
mail-lf0-f44.google.com[209.85.215.44]
Oct 18 09:52:24 raspberrypi postfix/smtp[3067]: CB7159DE68:
to=, orig_to=,
relay=gmail-smtp-in.l.google.com[66.102.1.26]:25, delay=0.53,
delays=0/0.02/0.27/0.24, dsn=2.0.0, status=sent (250 2.0.0 OK 1476780744
ma1si47546333wjb.183 - gsmtp)
Oct 18 09:52:24 raspberrypi postfix/qmgr[2125]: CB7159DE68: removed
Oct 18 09:52:52 raspberrypi postfix/smtpd[3061]: connect from
mail-lf0-f51.google.com[209.85.215.51]
Oct 18 09:52:53 raspberrypi postfix/smtpd[3061]: 26E0E9DE67:
client=mail-lf0-f51.google.com[209.85.215.51]
Oct 18 09:52:53 raspberrypi postfix/cleanup[3065]: 26E0E9DE67:
message-id=<15ee98e2-ef6a-f385-b0de-4cf94aa00...@gmail.com>
Oct 18 09:52:53 raspberrypi postfix/qmgr[2125]: 26E0E9DE67:
from=, size=2634, nrcpt=1 (queue active)
Oct 18 09:52:53 raspberrypi postfix/cleanup[3065]: 510909DE68:
message-id=<15ee98e2-ef6a-f385-b0de-4cf94aa00...@gmail.com>
Oct 

Problem with ldap failover

2016-10-21 Thread MichalZ
 Hi,

I have defined three ldap servers in the virtual_alias_maps lookup table,
but failover seems doesn't work. When I shutdown first ldap server I get
this error:

warning: ldap:/etc/postfix-in/ldap-mail-groups.cf lookup error
warning: dict_ldap_lookup: Search error -5: Timed out

which is correct, but users trying sent mails also gets 4xx error message
and postfix is still trying connect to the first ldap server. Do I missing
something in the configuration or ldap failover in the postfix doesn't work
correctly?

###
server_host =   ldaps://ldap3.img.local:636
ldaps://ldap2.img.local:636
ldaps://ldap.img.local:636
timeout = 3
version = 3
search_base = cn=users,cn=accounts,dc=img,dc=local
query_filter = (&(uid=%u))
result_attribute = street
bind = yes
bind_dn = uid=l_mail,cn=users,cn=accounts,dc=img,dc=local
bind_pw = xx
###

p.s. CentOS 7 - postfix-2.10.1-6.el7.x86_64

Thanks, Michal




--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Problem-with-ldap-failover-tp86824.html
Sent from the Postfix Users mailing list archive at Nabble.com.


Re: From in Body mail

2016-10-21 Thread /dev/rob0
On Thu, Oct 20, 2016 at 02:46:15PM +0100, Paweł Grzesik wrote:
> I noticed that it's really easy to send an e-mail as a real user
> by simply typing in the mail body:
> 
> From: 
> 
> Is there any way to prevent from this? I checked that even when
> we specify
> MAIL FROM: 
> 
> and then in the body:
> From: 
> 
> postfix will send an e-mail with From: , the one
> from the body. It sounds not right.

[Having read the rest of the thread] I think you are just now 
discovering what has been known about Internet mail for many years.

You might also be interested to know about the SMTP "envelope", which 
is the entire basis for mail and bounce routing.  Headers are not 
used for routing mail.  The "MAIL FROM:" address is the envelope 
sender (and the recipient if a bounce has to be sent), and the "RCPT 
TO:" addresses (there can be numerous given for a single mail 
transaction) are the envelope recipients.

See here if you want to control the use of bogus envelope senders in 
your domains:

http://www/postfix.org/postconf.5.html#smtpd_reject_unlisted_sender

If you're interested in somehow enforcing From: header and envelope 
sender matching, that cannot be done natively in Postfix.  And it's 
probably not a good idea anyway.  Consider this email and others you 
see from mailing lists.  Mine is sent out with:
"From: /dev/rob0 "
but you get it from the list server as envelope sender.

Read up about things like DKIM, SPF, DMARC, if you are interested in 
what others have been doing, trying to graft a fix for this problem 
onto the Internet mail specifications.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:


preserve recipient with catchall

2016-10-21 Thread Volker Cordes
Hello,

I have a domain where all mail is stored in a single mailbox and then
being fetched by a zarafa server via pop3. The zarafa server of course
has to be able to deliver the mails to the correct users. So I tried
adding X-Envelope-To via check_recipient_access which is working as long
as there only is one recipient.

With mulitiple recipients (to, cc and bcc fields) for each recipient
address a X-Envelope-To header is generated and the mail is delivered
once for every recipient into the catchall mailbox. Is it possible to
change this behaviour so that there is only one X-Envelope-To header in
every delivered mail?

Some more Information: I'm using amavis and tumpgreyfs and dovecot lmtp.

Any help would be appreciated,
Volker




Re: From in Body mail

2016-10-21 Thread Ralph Seichter
On 21.10.2016 08:50, Paweł Grzesik wrote:

> [user@mailtest ~]# telnet localhost 25
> [...]
> mynetworks_style = host

You're conducting your test from the machine Postfix is running on,
which is a member of 'mynetworks'...

> smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks

...and you give 'mynetworks' members permission to specify any envelope
recipient. Unless you have other restrictions in place, this means that
mail originating from localhost may be sent anywhere.

> smtpd_restriction_classes = insiders_only
> smtpd_sender_restrictions = check_sender_access 
> hash:/etc/postfix/sender_checks

Your postconf output missing the definition for 'insiders_only'. Also,
you did not show the contents of /etc/postfix/sender_checks.

-Ralph



Re: [Feature-request] (smtpd_)milter_exceptions

2016-10-21 Thread Christian Rößner
> Am 20.10.2016 um 14:11 schrieb Patrick Ben Koetter :
> 
> * Wietse Venema :
>> Christian Ro??ner:
>>> Possible situation: Central SMTP-hub that gets connections from
>>> MX-ins and internal servers, ...
>> 
>> I have a simpler solution: separate those mail streams with separate
>> MTA instances. That avoids the complexity of adding exceptions to
>> main.cf, milters, ...
>> 
>> Different streams can have different filters/milters, which is more
>> flexible than a milter on/off switch.
>> 
>> The two MTA instances can run on the same host (bound to different
>> IP addresses) or on separate hosts.
> 
> I expected this answer and obviously it makes sense to suggest this solution
> at first. We came up with that approach too, but had to give it up once we had
> a closer look at the environment the service runs in.
> 
> It is not always possible to use an additional IP address or port. Christian's
> RFE deals with exact these scenarios. We would use the simplier approach if it
> were possible.

I can confirm. There exist systems, were complexity raises, if you add a N-th 
listener to Postfix.

My idea was based on "smtpd_client_event_limit_exceptions".

Is there some hope that this feature might be implemented? I know milters exist 
for a longer time but my feeling is that popularity first came up in the last 
couple of years and it seems milter become more and more important. Therefor 
many systems do not use one or two milters at the time. I know about people who 
use up to ten milters in a system. Some more flexibility on Postfix smtpd-side 
would be really helpful here.

Thanks in advance

Christian
-- 
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com




Re: From in Body mail

2016-10-21 Thread Paweł Grzesik
Hi Noel,

This is how I'm doing it:

[user@mailtest ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailtest.example.com ESMTP Postfix
HELO mailtest
250 mailtest.example.com
MAIL FROM: 
250 2.1.0 Ok
RCPT TO: pa...@example.com
250 2.1.5 Ok
DATA
354 End data with .
From: j...@mailtest.example.com
To: pa...@mailtest.example.com
Subject: Testing SCAM
Text: ABC123
.
250 2.0.0 Ok: queued as 481D6C76B6

And this is my postfix config:

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_min_user = no
biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
local_recipient_maps = hash:/etc/postfix/local_recipients
mail_owner = postfix
mailbox_size_limit = 222880
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 25165824
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
mail.$mydomain, mmsin.$mydomain
mydomain = mailtest.example.com
myhostname = mailtest.example.com
mynetworks_style = host
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sender_bcc_maps = hash:/etc/postfix/bcc_maps
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
show_user_unknown_table_name = no
smtpd_hard_error_limit = 10
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks,   check_helo_access hash:/etc/postfix/helo_checks,
check_sender_access regexp:/etc/postfix/alert_redirections,
check_client_access hash:/etc/postfix/live_systems,   check_client_access
hash:/etc/postfix/rbl_whitelist,   check_recipient_access
pcre:/etc/postfix/special_recipients,   reject_unauth_pipelining,
reject_unauth_destination,   check_client_access
hash:/etc/postfix/opera_access,   check_client_access
hash:/etc/postfix/epdq_access,   check_sender_access
pcre:/etc/postfix/sender_address_checks,   reject_non_fqdn_sender,
reject_non_fqdn_recipient,   reject_rbl_client truncate.gbudb.net,
reject_rbl new.spam.dnsbl.sorbs.net,   reject_rbl zen.spamhaus.org,
check_sender_access regexp:/etc/postfix/reject_fake_brainstorm,   permit
smtpd_restriction_classes = insiders_only
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = check_sender_access
hash:/etc/postfix/sender_checks
smtpd_timeout = 45s
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/mailtest.example.com.crt
smtpd_tls_key_file = /etc/pki/tls/private/mailtest.example.com.key
smtpd_tls_security_level = may
virtual_alias_domains = o2open.co.uk
virtual_alias_maps = pcre:/etc/postfix/virtual

Thanks,
Pawel

2016-10-20 21:41 GMT+01:00 Noel Jones :

> On 10/20/2016 3:08 PM, Paweł Grzesik wrote:
> > Just telnet on any host on 25 port and type From: some_real_email
> > and email will be send. I think thats how scam works.
>
>
> That doesn't work with postfix.  Either your description or your
> test method is wrong.
>
>
> $ telnet localhost 25
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 server.example.com ESTMP
> From: u...@example.com
> 221 2.7.0 Error: I can break rules, too. Goodbye.
> Connection closed by foreign host.
>
>
>
>
>


Re: Postfix persistent connection and MySQL cluster

2016-10-21 Thread Niklaas Baudet von Gersdorff
t...@iredmail.org [2016-10-21 00:11 +0200] :

> We use the floating IP address (handled by KeepAlived) in Postfix config
> file, we expect Postfix can always connect to a mysql server.

I have a similar set up (instead of MySQL I use OpenLDAP though).
Assuming that your servers are in a VPN, why don't you configure
Postfix to use one (or both) of your proxies via their private
addresses? The proxies will then distribute the traffic to
available MySQL instances.

> The problem is, Postfix keeps persist sql connection to this
> server itself, if currently connected mysql server is down,
> HAProxy will redispatch the mysql request to another backend
> (this is expected), this breaks the persist sql connection
> maintained by Postfix itself, so Postfix will raise error and
> cannot reconnect.

Have you configured

  no option http-server-close

  
http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#no%20option%20http-server-close

for your MySQL frontend/backend in HAProxy?

> *) Postfix supports auto reconnecting to another mysql server if we list
> several mysql servers in its config file, but we have only one - the
> floating IP address.

You have: The two private addresses of your proxies.

> *) Postfix also supports auto reconnecting if we use a domain name (with
> multiple A records in DNS) or multiple mysql nodes IPs as sql server
> address. although no error raised with this method, we lose the load-balance
> feature for mysql request.

You could configure your own DNS that does support this idea.



Re: Is my server mail account being attacted?

2016-10-21 Thread vod vos
Yes, I did not  advertise AUTH in my port 25 smtpd too. when telnet to my mail 
server, it produce like:



telnet 108.61.110.110 25

Trying 108.61.110.110...

Connected to example.com.

Escape character is '^]'.

220 example ESMTP Postfix

ehlo

501 Syntax: EHLO hostname

ehlo mail

250-mail.example

250-PIPELINING

250-SIZE 1024

250-VRFY

250-ETRN

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-8BITMIME

250-DSN

250 SMTPUTF8

AUTH PLAIN

503 5.5.1 Error: authentication not enabled



I am going to add some iptables rules to ban some ip now.


 On 星期四, 20 十月 2016 14:13:26 -0700Bill Cole 
postfixlists-070...@billmail.scconsult.com wrote 




On 20 Oct 2016, at 16:39, Keith Williams wrote: 



 No wait... What? 

 

 This is no attack. Attack is when you try to break or enforce.. This 

 is a probe, and from the probe we can deduce from the reported 

 disconnect that 1. helo was tried, 2. no auth was attempted and 3, 

 quit was used. 

 

 So a test for helo and quit? and no auth. 



No. The "auth=0/1" in the disconnect line means that Postfix received 1 

authentication attempt but it failed. This was a "probe" to see if a 

particular user exists and has a particular password. 



 Someone is testing your IP and mail capibility.. perhaps 



Not stipulating that unauthorized "probes" are not also block-worthy, 

but this is a bit more. 



 On 20/10/2016 22:20, Bill Cole wrote: 

 On 18 Oct 2016, at 20:45, Sebastian Nielsen wrote: 

 

 Its clear from the log, the attacker isn't even attemping to 

 authenticate (0 attempts). The attacker hasn't propably not even 

 realized he is connecting to a mail server. 

 

 

 No. There's a jumble there, but at least one is a lame "attack" of a 

 sort. The only *Postfix* messages were: 

 

 Oct 19 07:55:27 mail postfix/smtpd[9929]: connect from 

 unknown[216.15.186.126] 

 Oct 19 07:55:28 mail postfix/smtpd[9929]: disconnect from 

 unknown[216.15.186.126] helo=1 auth=0/1 quit=1 commands=2/3 

 

 *THAT* client tried to authenticate and failed. It's a CBL-listed IP 

 on a chronically abuse-friendly network. 

 

 The rest were all messages from Dovecot components, about failed SSL 

 connections from a mix of IPs. Impossible to know what the reasons 

 for those were without tracking down the person running the computer.