Best practices link for postscreen

2019-06-22 Thread Durga Prasad Malyala
Hi
Does anyone have best practices link for postscreen implementation.

Thank you
DP


Re: Best practices link for postscreen

2019-06-22 Thread postfix
Sat, 22 Jun 2019 12:48:36 +0530 skrev Durga Prasad Malyala
:

> Hi
> Does anyone have best practices link for postscreen implementation.
> 
> Thank you
> DP

The how-to document might be a good start

https://postfix.aptget.dk/POSTSCREEN_README.html

The best,


Re: Best practices link for postscreen

2019-06-22 Thread Lefteris Tsintjelis
On 22/6/2019 10:18, Durga Prasad Malyala wrote:
> Hi
> Does anyone have best practices link for postscreen implementation.

http://rob0.nodns4.us/postscreen.html
http://www.postfix.org/POSTSCREEN_README.html

It is a start but I would also like to see more examples and
recommendations in more advanced setups like multiple MXs sharing the
same cache map for example, together with additional IPs in multiple
servers to permanently block invalid attempts.

Lefteris


Re: Greylisting -- current recommendations?

2019-06-22 Thread A. Schulze



Am 22.06.19 um 02:49 schrieb Rich Wales:
> Any other suggestions?

I'm still using greylisting with moderate effects. It catches some percent 
other AntiSpam technics doesn't

Andreas


Re: Best practices link for postscreen

2019-06-22 Thread Wietse Venema
Lefteris Tsintjelis:
> On 22/6/2019 10:18, Durga Prasad Malyala wrote:
> > Hi
> > Does anyone have best practices link for postscreen implementation.
> 
> http://rob0.nodns4.us/postscreen.html
> http://www.postfix.org/POSTSCREEN_README.html
> 
> It is a start but I would also like to see more examples and
> recommendations in more advanced setups like multiple MXs sharing the
> same cache map for example, together with additional IPs in multiple
> servers to permanently block invalid attempts.

Sharing a non-persistent cache (memcache) is the only option because
it can respond with low latency both for old and new queries. But
that of course limits the cache size.

Sharing a persistent cache is not an option because that requires
a DBMS with milliscond query latency (with a query latency of 50ms,
one postscreen instance would handle at most 20 clients per second).

You could try to combine a shared memcache and a shared persistent
cache, but that will only improve the best case where most connections
come from a limited set of clients. The memcache will not improve
the worst case, for example a backscatter scenario where most clients
are clients new. In that case the postscreen performance would be
exactly as bad as in the previous paragraph.

With Internet services, it would be a mistake to optimize the best
case only; especially if it makes worst-case behavior worse.

Wietse


Re: Unable to send or receive from Gmail

2019-06-22 Thread Security Admin (NetSec)
I figured TLS 1.3 might be the culprit from the logs.  The OpenSSL version 
shows "OpenSSL 1.1.1   11 Sep 2018" and it was updated recently via Ubuntu.

How might I go about not negotiating TLS 1.3, as it is obvious I need to update 
some certificates (which I will worry about later).

Edward Ray 

On 6/21/19, 10:36 PM, "owner-postfix-us...@postfix.org on behalf of Viktor 
Dukhovni"  wrote:

On Sat, Jun 22, 2019 at 04:09:45AM +, Security Admin (NetSec) wrote:

> Within the last week or so I am suddenly unable to send or receive from
> Google Gmail.  Any help with this issue would be appreciated.

What version of OpenSSL is installed on your system?  Was it upgraded
recently?  You are now negotiating TLSv1.3, was that the case previously?

> Receive Error from mail.log:
> 
> Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 write 
server certificate verify
> Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write 
finished

Your SMTP server has just sent its certificate chain, and signature
over the handshake transcript (so far).

> Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL3 alert read:fatal:illegal 
parameter

The SMTP client responds with an "illegal parameter" alert.  As yet,
unclear why.

> Send Error from mail.log:
> 
> Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write 
certificate
> Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 write 
server certificate verify

Sadly this too is a receive log.

-- 
Viktor.




Re: Unable to send or receive from Gmail

2019-06-22 Thread lists
  OK, but then I would verify the cert your are using and would still fix this cert since ssllabs says it is not trusted.    From: secad...@netsecdesign.comSent: June 22, 2019 8:03 AMTo: li...@lazygranch.com; postfix-users@postfix.orgSubject: Re: Unable to send or receive from Gmail  
The website for “netsecdesign.com” is different than the one for my postfix gateway.  Different machine, different IP address, different cert.
 
 

From:  on behalf of lists 
Date: Friday, June 21, 2019 at 10:13 PM
To: Security Admin , "postfix-users@postfix.org" 
Subject: Re: Unable to send or receive from Gmail


 



If you are netsecdesign.com, ssllabs says your cert has issues. Not that this may be your problem, but I would fix that first. 


 






From:  secad...@netsecdesign.com


Sent: June 21, 2019 9:19 PM


To:  postfix-users@postfix.org


Subject: Unable to send or receive from Gmail



 





Within the last week or so I am suddenly unable to send or receive from Google Gmail.  Any help with this issue would be appreciated.
 
Receive Error from
mail.log:
 
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write certificate
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 write server certificate verify
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write finished
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 early data
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL3 alert read:fatal:illegal parameter
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:error in error
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept error from
mail-wm1-f52.google.com[209.85.128.52]: -1
Jun 21 20:59:26 portus postfix/smtpd[3726]: warning: TLS library problem: error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:../ssl/record/rec_layer_s3.c:1528:SSL
 alert number 47:
Jun 21 20:59:26 portus postfix/smtpd[3726]: lost connection after STARTTLS from
mail-wm1-f52.google.com[209.85.128.52]
Jun 21 20:59:26 portus postfix/smtpd[3726]: disconnect from
mail-wm1-f52.google.com[209.85.128.52] ehlo=1 starttls=0/1 commands=1/2
 
 
 
 
Send Error from
mail.log:
 
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write certificate
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 write server certificate verify
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write finished
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 early data
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL3 alert read:fatal:illegal parameter
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:error in error
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept error from
mail-pl1-f180.google.com[209.85.214.180]: -1
Jun 21 21:05:47 portus postfix/smtpd[3726]: warning: TLS library problem: error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:../ssl/record/rec_layer_s3.c:1528:SSL
 alert number 47:
Jun 21 21:05:47 portus postfix/smtpd[3726]: lost connection after STARTTLS from
mail-pl1-f180.google.com[209.85.214.180]
Jun 21 21:05:47 portus postfix/smtpd[3726]: disconnect from
mail-pl1-f180.google.com[209.85.214.180] ehlo=1 starttls=0/1 commands=1/2







Re: Unable to send or receive from Gmail

2019-06-22 Thread Security Admin (NetSec)
The website for “netsecdesign.com” is different than the one for my postfix 
gateway.  Different machine, different IP address, different cert.


From:  on behalf of lists 

Date: Friday, June 21, 2019 at 10:13 PM
To: Security Admin , "postfix-users@postfix.org" 

Subject: Re: Unable to send or receive from Gmail

If you are netsecdesign.com, ssllabs says your cert has issues. Not that this 
may be your problem, but I would fix that first.

From: secad...@netsecdesign.com
Sent: June 21, 2019 9:19 PM
To: postfix-users@postfix.org
Subject: Unable to send or receive from Gmail


Within the last week or so I am suddenly unable to send or receive from Google 
Gmail.  Any help with this issue would be appreciated.

Receive Error from mail.log:

Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write 
certificate
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 write server 
certificate verify
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write finished
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 early data
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL3 alert read:fatal:illegal 
parameter
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:error in error
Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept error from 
mail-wm1-f52.google.com[209.85.128.52]:
 -1
Jun 21 20:59:26 portus postfix/smtpd[3726]: warning: TLS library problem: 
error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal 
parameter:../ssl/record/rec_layer_s3.c:1528:SSL alert number 47:
Jun 21 20:59:26 portus postfix/smtpd[3726]: lost connection after STARTTLS from 
mail-wm1-f52.google.com[209.85.128.52]
Jun 21 20:59:26 portus postfix/smtpd[3726]: disconnect from 
mail-wm1-f52.google.com[209.85.128.52]
 ehlo=1 starttls=0/1 commands=1/2




Send Error from mail.log:

Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write 
certificate
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 write server 
certificate verify
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS write finished
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 early data
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL3 alert read:fatal:illegal 
parameter
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:error in error
Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept error from 
mail-pl1-f180.google.com[209.85.214.180]:
 -1
Jun 21 21:05:47 portus postfix/smtpd[3726]: warning: TLS library problem: 
error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal 
parameter:../ssl/record/rec_layer_s3.c:1528:SSL alert number 47:
Jun 21 21:05:47 portus postfix/smtpd[3726]: lost connection after STARTTLS from 
mail-pl1-f180.google.com[209.85.214.180]
Jun 21 21:05:47 portus postfix/smtpd[3726]: disconnect from 
mail-pl1-f180.google.com[209.85.214.180]
 ehlo=1 starttls=0/1 commands=1/2


Re: Unable to send or receive from Gmail (temp solution)

2019-06-22 Thread Security Admin (NetSec)
Doh! 

!TLSv1.3 added to "main.conf" fixed the issue hopefully.  

Will work on updating certificate later...


On 6/22/19, 8:10 AM, "owner-postfix-us...@postfix.org on behalf of Security 
Admin (NetSec)"  wrote:

I figured TLS 1.3 might be the culprit from the logs.  The OpenSSL version 
shows "OpenSSL 1.1.1   11 Sep 2018" and it was updated recently via Ubuntu.

How might I go about not negotiating TLS 1.3, as it is obvious I need to 
update some certificates (which I will worry about later).

Edward Ray 

On 6/21/19, 10:36 PM, "owner-postfix-us...@postfix.org on behalf of Viktor 
Dukhovni"  wrote:

On Sat, Jun 22, 2019 at 04:09:45AM +, Security Admin (NetSec) wrote:

> Within the last week or so I am suddenly unable to send or receive 
from
> Google Gmail.  Any help with this issue would be appreciated.

What version of OpenSSL is installed on your system?  Was it upgraded
recently?  You are now negotiating TLSv1.3, was that the case 
previously?

> Receive Error from mail.log:
> 
> Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 write 
server certificate verify
> Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS 
write finished

Your SMTP server has just sent its certificate chain, and signature
over the handshake transcript (so far).

> Jun 21 20:59:26 portus postfix/smtpd[3726]: SSL3 alert 
read:fatal:illegal parameter

The SMTP client responds with an "illegal parameter" alert.  As yet,
unclear why.

> Send Error from mail.log:
> 
> Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:SSLv3/TLS 
write certificate
> Jun 21 21:05:47 portus postfix/smtpd[3726]: SSL_accept:TLSv1.3 write 
server certificate verify

Sadly this too is a receive log.

-- 
Viktor.






Re: Unable to send or receive from Gmail

2019-06-22 Thread Security Admin (NetSec)
" If you are netsecdesign.com, ssllabs says your cert has issues. Not that this 
may be your problem, but I would fix that first."

This cert is not the same cert or the same server or the same IP address as my 
postfix SMTP gateway.

The postfix SMTP gateway uses a self-signed certificate.


On 6/21/19, 10:42 PM, "owner-postfix-us...@postfix.org on behalf of Viktor 
Dukhovni"  wrote:

> On Jun 22, 2019, at 1:12 AM, lists  wrote:
> 
> If you are netsecdesign.com, ssllabs says your cert has issues. Not that 
this may be your problem, but I would fix that first. 

The certificate is past its nominal expiration, but perhaps
more importantly its "Basic Key Usage" field says:

X509v3 Key Usage:
Certificate Sign

which does not include digitalSignature, and that's most likely
the issue.  A more appropriate certificate is more likely to work.

Gmail IIRC enforces more TLS hygiene when TLSv1.3 is negotiated.

-- 
Viktor.





disable TLS 1.3 on postfix

2019-06-22 Thread Security Admin (NetSec)
What is the correct procedure to disable TLS 1.3 negotiation on postfix?




Re: disable TLS 1.3 on postfix

2019-06-22 Thread Benny Pedersen

Security Admin (NetSec) skrev den 2019-06-22 19:15:
What is the correct procedure to disable TLS 1.3 negotiation on 
postfix?


why ?

i am not an expert, but i think you will not get that to work well, imho 
show logs for the problem to get more help


Re: disable TLS 1.3 on postfix (logs enclosed)

2019-06-22 Thread Benny Pedersen

Security Admin (NetSec) skrev den 2019-06-22 19:34:


Jun 22 10:31:19 mailgate postfix/smtpd[7180]: warning: TLS library
problem: error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert
illegal parameter:../ssl/record/rec_layer_s3.c:1528:SSL alert number
47:


this is a ssl3 disabled in openssl problem, not a tls 1.3 problem

remote needs openssl upgrade


Re: disable TLS 1.3 on postfix (logs enclosed)

2019-06-22 Thread Security Admin (NetSec)
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: setting up TLS connection from 
mail-wr1-f42.google.com[209.85.221.42]
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: 
mail-wr1-f42.google.com[209.85.221.42]: TLS cipher list 
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:before SSL 
initialization
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:before SSL 
initialization
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:SSLv3/TLS read client 
hello
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:SSLv3/TLS write server 
hello
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:SSLv3/TLS write change 
cipher spec
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:TLSv1.3 write 
encrypted extensions
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:SSLv3/TLS write 
certificate
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:TLSv1.3 write server 
certificate verify
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:SSLv3/TLS write 
finished
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:TLSv1.3 early data
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL3 alert read:fatal:illegal 
parameter
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept:error in error
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: SSL_accept error from 
mail-wr1-f42.google.com[209.85.221.42]: -1
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: warning: TLS library problem: 
error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal 
parameter:../ssl/record/rec_layer_s3.c:1528:SSL alert number 47:
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: lost connection after STARTTLS 
from mail-wr1-f42.google.com[209.85.221.42]
Jun 22 10:31:19 mailgate postfix/smtpd[7180]: disconnect from 
mail-wr1-f42.google.com[209.85.221.42] ehlo=1 starttls=0/1 commands=1/2

On 6/22/19, 10:31 AM, "owner-postfix-us...@postfix.org on behalf of Benny 
Pedersen"  wrote:

Security Admin (NetSec) skrev den 2019-06-22 19:15:
> What is the correct procedure to disable TLS 1.3 negotiation on 
> postfix?

why ?

i am not an expert, but i think you will not get that to work well, imho 
show logs for the problem to get more help




Re: TLS 1.3 on postfix (fixed)

2019-06-22 Thread Security Admin (NetSec)
Apologies for multiple emails to this list for the same problem.

Some internet searches got me to the right solution.

One of the other posters was correct; it was a certificate issue.  Reissued my 
cert on my postfix SMTP mail gateways.

All seems to be working now.  Gmail defaults to TLS 1.2

I saw some posts that TLS 1.3 still has issues with OpenSSL v1.1.1 and postfix 
3.3.x

I am using Ubuntu Linux and the latest postfix which is 3.3.0 unfortunately


Edward Ray






Re: TLS 1.3 on postfix (fixed)

2019-06-22 Thread Benny Pedersen

Security Admin (NetSec) skrev den 2019-06-22 20:20:

I am using Ubuntu Linux and the latest postfix which is 3.3.0 
unfortunately


hope google stop failback from tls to ssl :(

good you solved your part of the problem


Re: Best practices link for postscreen

2019-06-22 Thread Lefteris Tsintjelis

On 22/6/2019 17:36, Wietse Venema wrote:


Sharing a non-persistent cache (memcache) is the only option because
it can respond with low latency both for old and new queries. But
that of course limits the cache size.

Sharing a persistent cache is not an option because that requires
a DBMS with milliscond query latency (with a query latency of 50ms,
one postscreen instance would handle at most 20 clients per second).


DBMS would very possibly be slow for large backscatter scenarios.


You could try to combine a shared memcache and a shared persistent
cache, but that will only improve the best case where most connections
come from a limited set of clients. The memcache will not improve
the worst case, for example a backscatter scenario where most clients
are clients new. In that case the postscreen performance would be
exactly as bad as in the previous paragraph.


Wouldn't the worst case scenario with many new clients improve also by 
reducing latency though? I suspect this has a lot to do with DNSBL 
response time(???) or maybe there are other important delay factors 
besides that? What I have in mind is a local only postscreen DNSBL and 
the 50ms can easily go down to a millisecond.



With Internet services, it would be a mistake to optimize the best
case only; especially if it makes worst-case behavior worse.


Lefteris


Re: disable TLS 1.3 on postfix

2019-06-22 Thread Viktor Dukhovni



> On Jun 22, 2019, at 1:30 PM, Benny Pedersen  wrote:
> 
>> What is the correct procedure to disable TLS 1.3 negotiation on postfix?
> 
> why ?
> 
> i am not an expert, [...]

Best to hold back in that case...  The right answer is:

  http://www.postfix.org/postconf.5.html#smtpd_tls_protocols
  http://www.postfix.org/postconf.5.html#smtp_tls_protocols

-- 
Viktor.



Re: TLS 1.3 on postfix (fixed)

2019-06-22 Thread Viktor Dukhovni



> On Jun 22, 2019, at 2:20 PM, Security Admin (NetSec) 
>  wrote:
> 
> One of the other posters was correct; it was a certificate issue.  Reissued 
> my cert on my postfix SMTP mail gateways.

As expected, the keyUsage you had was only appropriate for a CA,
not a TLS server.

> All seems to be working now.  Gmail defaults to TLS 1.2

Whatever the default, the logs you posted showed TLS 1.3

> I saw some posts that TLS 1.3 still has issues with OpenSSL v1.1.1 and 
> postfix 3.3.x

Postfix 3.3 should works fine with TLS 1.3, but Postfix 3.4 has improved
support.

-- 
Viktor.



Gave up on my ISP, trying to get GMail to work but get - host smtp.gmail.com[64.233.168.108] said: 530-5.5.1 Authentication Required.

2019-06-22 Thread Chris Pollock
In my previous post - "How to tell my ISP there's a problem" I wasn't
able to figure out the problem and CenturyLink is no help so I decided
to use my GMail account to send my messages from cron. However I've run
into a problem that I keep getting the message that's in the subject.
I've pasted the complete output of a test run below:

https://pastebin.com/fLBqL1e0

Here is my main.cf

https://pastebin.com/1mmEP89b

I'm sure I have something just not right but I can't see what it is. 

Thanks for any advise

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
17:19:29 up 1 day, 23:29, 1 user, load average: 1.00, 1.00, 1.15
Description:Ubuntu 18.04.2 LTS, kernel 4.18.0-22-generic


signature.asc
Description: This is a digitally signed message part


Re: Best practices link for postscreen

2019-06-22 Thread Wietse Venema
Lefteris Tsintjelis:
> On 22/6/2019 17:36, Wietse Venema wrote:
> > 
> > Sharing a non-persistent cache (memcache) is the only option because
> > it can respond with low latency both for old and new queries. But
> > that of course limits the cache size.
> > 
> > Sharing a persistent cache is not an option because that requires
> > a DBMS with milliscond query latency (with a query latency of 50ms,
> > one postscreen instance would handle at most 20 clients per second).
> 
> DBMS would very possibly be slow for large backscatter scenarios.
> 
> > You could try to combine a shared memcache and a shared persistent
> > cache, but that will only improve the best case where most connections
> > come from a limited set of clients. The memcache will not improve
> > the worst case, for example a backscatter scenario where most clients
> > are clients new. In that case the postscreen performance would be
> > exactly as bad as in the previous paragraph.
> 
> Wouldn't the worst case scenario with many new clients improve also by 
> reducing latency though? I suspect this has a lot to do with DNSBL 
> response time(???) or maybe there are other important delay factors 
> besides that? What I have in mind is a local only postscreen DNSBL and 
> the 50ms can easily go down to a millisecond.

FYI, postscreen queries its cache BEFORE it decides if DNSXL checks
are needed. Therefore you can't speed up postscreen cache queries
with faster DNS.

Wietse


Re: Gave up on my ISP, trying to get GMail to work but get - host smtp.gmail.com[64.233.168.108] said: 530-5.5.1 Authentication Required.

2019-06-22 Thread Wietse Venema
Chris Pollock:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> In my previous post - "How to tell my ISP there's a problem" I wasn't
> able to figure out the problem and CenturyLink is no help so I decided
> to use my GMail account to send my messages from cron. However I've run
> into a problem that I keep getting the message that's in the subject.
> I've pasted the complete output of a test run below:
> 
> https://pastebin.com/fLBqL1e0

Did you read the message?

Jun 22 17:17:51 localhost postfix/smtp[11023]: C40181000BA2: 
to=, relay=smtp.gmail.com[64.233.168.108]:587, 
delay=0.32, delays=0.05/0/0.24/0.03, dsn=5.5.1, status=bounced (host 
smtp.gmail.com[64.233.168.108] said: 530-5.5.1 Authentication Required. Learn 
more at 530 5.5.1  https://support.google.com/mail/?p=WantAuthError 
t30sm2748311otb.50 - gsmtp (in reply to MAIL FROM command))

And the web page in the link says:

Outgoing Mail (SMTP) Server
smtp.gmail.com <=== good. you use this.
...(requires SSL or TLS) <== good. you use this.
Requires Authentication: Yes <== ERROR YOU ARE NOT DOING THIS.
...
Port for TLS/STARTTLS: 587 <=== good. you use this.

Account Name, User name, or Email address
Your full email address

Password
Your Gmail password

To configure SASL authentication, put your user name (Your full
email address) and password (Your Gmail password) in smtp_sasl_passwd
maps as described in http://www.postfix.org/SASL_README.html

The text in /etc/postfix/sasl_passwd should look like:

smtp.gmail.com  Your-full-email-address:Your-Gmail-password

and you should run "postmap hash:/etc/postfix/sasl_passwd"
before using that file.

Wietse


havedane dns issues

2019-06-22 Thread Thilo Molitor
Anybody on this list having contact to the maintainer / webmaster of 
havedane.net ?
It's having dns issues when the TLSA record is queried with qname minimization 
active (RFC 7186).
This is a bug in the dns server or dnssec signer and should be fixed.
Otherwise false negatives are generated!

See this dnsviz link for a description of what is wrong: http://dnsviz.net/d/
_25._tcp.do.havedane.net/dnssec/

- tmolitor


Re: Gave up on my ISP, trying to get GMail to work but get - host smtp.gmail.com[64.233.168.108] said: 530-5.5.1 Authentication Required.

2019-06-22 Thread Chris Pollock
On Sat, 2019-06-22 at 19:12 -0400, Wietse Venema wrote:
> Chris Pollock:
> 
> Checking application/pgp-signature: FAILURE
> -- Start of PGP signed section.
> > In my previous post - "How to tell my ISP there's a problem" I
> > wasn't
> > able to figure out the problem and CenturyLink is no help so I
> > decided
> > to use my GMail account to send my messages from cron. However I've
> > run
> > into a problem that I keep getting the message that's in the
> > subject.
> > I've pasted the complete output of a test run below:
> > 
> > https://pastebin.com/fLBqL1e0
> 
> Did you read the message?
> 
> Jun 22 17:17:51 localhost postfix/smtp[11023]: C40181000BA2:
> to=,
> relay=smtp.gmail.com[64.233.168.108]:587, delay=0.32,
> delays=0.05/0/0.24/0.03, dsn=5.5.1, status=bounced (host
> smtp.gmail.com[64.233.168.108] said: 530-5.5.1 Authentication
> Required. Learn more at 530 5.5.1  
> https://support.google.com/mail/?p=WantAuthError t30sm2748311otb.50 -
> gsmtp (in reply to MAIL FROM command))
> 
> And the web page in the link says:
> 
> Outgoing Mail (SMTP) Server
> smtp.gmail.com <=== good. you use this.
> ...(requires SSL or TLS) <== good. you use this.
> Requires Authentication: Yes <== ERROR YOU ARE NOT DOING
> THIS.
> ...
> Port for TLS/STARTTLS: 587 <=== good. you use this.
> 
> Account Name, User name, or Email address
> Your full email address
> 
> Password
> Your Gmail password
> 
> To configure SASL authentication, put your user name (Your full
> email address) and password (Your Gmail password) in smtp_sasl_passwd
> maps as described in http://www.postfix.org/SASL_README.html
> 
> The text in /etc/postfix/sasl_passwd should look like:
> 
> smtp.gmail.comYour-full-email-address:Your-Gmail-password
> 
> and you should run "postmap hash:/etc/postfix/sasl_passwd"
> before using that file.
> 
>   Wietse

I've spent 3hrs going over and over my settings and can't find where
I've got a problem. My /etc/postfix/sasl_passwd file contains:

smtp.gmail.com:587 chris.pollock1...@gmail.com:*

I've run postmap hash:/etc/postfix/sasl_passwd and still get the same
authentication error above and each time I run sudo postfix reload. I
know my password is correct because it's the same I use for fetchmail.
I even logged out and back in on my browser to be sure.

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
20:40:08 up 2 days, 2:50, 1 user, load average: 1.69, 1.15, 1.07
Description:Ubuntu 18.04.2 LTS, kernel 4.18.0-22-generic


signature.asc
Description: This is a digitally signed message part


Re: Gave up on my ISP, trying to get GMail to work but get - host smtp.gmail.com[64.233.168.108] said: 530-5.5.1 Authentication Required.

2019-06-22 Thread Sonic
I don't think you can use gmail as a relay host unless Google is
handling your domain's mail service (a GSuite account - not @gmail.com
addresses). They have instructions for setting this up and the proper
relay host once you've done the admin work is "relayhost =
smtp-relay.gmail.com:587" (at least this works for me).

On Sat, Jun 22, 2019 at 9:58 PM Chris Pollock  wrote:
>
> On Sat, 2019-06-22 at 19:12 -0400, Wietse Venema wrote:
> > Chris Pollock:
> >
> > Checking application/pgp-signature: FAILURE
> > -- Start of PGP signed section.
> > > In my previous post - "How to tell my ISP there's a problem" I
> > > wasn't
> > > able to figure out the problem and CenturyLink is no help so I
> > > decided
> > > to use my GMail account to send my messages from cron. However I've
> > > run
> > > into a problem that I keep getting the message that's in the
> > > subject.
> > > I've pasted the complete output of a test run below:
> > >
> > > https://pastebin.com/fLBqL1e0
> >
> > Did you read the message?
> >
> > Jun 22 17:17:51 localhost postfix/smtp[11023]: C40181000BA2:
> > to=,
> > relay=smtp.gmail.com[64.233.168.108]:587, delay=0.32,
> > delays=0.05/0/0.24/0.03, dsn=5.5.1, status=bounced (host
> > smtp.gmail.com[64.233.168.108] said: 530-5.5.1 Authentication
> > Required. Learn more at 530 5.5.1
> > https://support.google.com/mail/?p=WantAuthError t30sm2748311otb.50 -
> > gsmtp (in reply to MAIL FROM command))
> >
> > And the web page in the link says:
> >
> > Outgoing Mail (SMTP) Server
> > smtp.gmail.com <=== good. you use this.
> > ...(requires SSL or TLS) <== good. you use this.
> > Requires Authentication: Yes <== ERROR YOU ARE NOT DOING
> > THIS.
> > ...
> > Port for TLS/STARTTLS: 587 <=== good. you use this.
> >
> > Account Name, User name, or Email address
> > Your full email address
> >
> > Password
> > Your Gmail password
> >
> > To configure SASL authentication, put your user name (Your full
> > email address) and password (Your Gmail password) in smtp_sasl_passwd
> > maps as described in http://www.postfix.org/SASL_README.html
> >
> > The text in /etc/postfix/sasl_passwd should look like:
> >
> > smtp.gmail.comYour-full-email-address:Your-Gmail-password
> >
> > and you should run "postmap hash:/etc/postfix/sasl_passwd"
> > before using that file.
> >
> >   Wietse
>
> I've spent 3hrs going over and over my settings and can't find where
> I've got a problem. My /etc/postfix/sasl_passwd file contains:
>
> smtp.gmail.com:587 chris.pollock1...@gmail.com:*
>
> I've run postmap hash:/etc/postfix/sasl_passwd and still get the same
> authentication error above and each time I run sudo postfix reload. I
> know my password is correct because it's the same I use for fetchmail.
> I even logged out and back in on my browser to be sure.
>
> --
> Chris
> KeyID 0xE372A7DA98E6705C
> 31.11972; -97.90167 (Elev. 1092 ft)
> 20:40:08 up 2 days, 2:50, 1 user, load average: 1.69, 1.15, 1.07
> Description:Ubuntu 18.04.2 LTS, kernel 4.18.0-22-generic


Re: Gave up on my ISP, trying to get GMail to work but get - host smtp.gmail.com[64.233.168.108] said: 530-5.5.1 Authentication Required.

2019-06-22 Thread Viktor Dukhovni
On Sat, Jun 22, 2019 at 08:56:35PM -0500, Chris Pollock wrote:

> I've spent 3hrs going over and over my settings and can't find where
> I've got a problem. My /etc/postfix/sasl_passwd file contains:
> 
> smtp.gmail.com:587 chris.pollock1...@gmail.com:*

Since your relayhost setting is:

  relayhost = [smtp.gmail.com]:587

Your SASL password should (IIRC) be either:

  [smtp.gmail.com]:587 chris.pollock1...@gmail.com:*

or

  smtp.gmail.com chris.pollock1...@gmail.com:*

the version without the [], but the port might not work, as it is
neither the full destination, nor the underlying host.

-- 
Viktor.


Re: havedane dns issues

2019-06-22 Thread Viktor Dukhovni
On Sun, Jun 23, 2019 at 02:10:39AM +0200, Thilo Molitor wrote:

> Anybody on this list having contact to the maintainer / webmaster of 
> havedane.net ?

I just sent an email via the contact form.

> It's having dns issues when the TLSA record is queried with qname 
> minimization 
> active (RFC 7186).
> This is a bug in the dns server or dnssec signer and should be fixed.
> Otherwise false negatives are generated!

Yes, incorrect handling of empty-non-terminals.  I don't enable
qname minimization on the unbound instance on my MTA.  Still tends
to run into bugs like this now and then.

-- 
Viktor.


Re: disable TLS 1.3 on postfix (logs enclosed)

2019-06-22 Thread Viktor Dukhovni
On Sat, Jun 22, 2019 at 07:38:32PM +0200, Benny Pedersen wrote:

> Security Admin (NetSec) skrev den 2019-06-22 19:34:
> 
> > Jun 22 10:31:19 mailgate postfix/smtpd[7180]: warning: TLS library
> > problem: error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert
> > illegal parameter:../ssl/record/rec_layer_s3.c:1528:SSL alert number
> > 47:
> 
> this is a ssl3 disabled in openssl problem, not a tls 1.3 problem
> 
> remote needs openssl upgrade

No. Please don't just make stuff up.

-- 
Viktor.