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.
On Mon, 2019-06-24 at 08:00 +1200, Peter wrote: > On 24/06/19 3:38 AM, Chris Pollock wrote: > > I still have some that are going to /var/spool/mail/nobody however. > > Headers below: > > And your logs show what exactly? > > > Peter The pastes are from my mail.log https://pastebin.com/2kn42CRa As I said earlier it all seems to be working correctly now. -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 16:50:32 up 2 days, 23:00, 1 user, load average: 1.25, 1.20, 1.01 Description:Ubuntu 18.04.2 LTS, kernel 4.18.0-22-generic signature.asc Description: This is a digitally signed message part
Re: Smptd intruder
John Plate: > Hi > > I introduced "smtpd_reject_unlisted_sender=yes" in main.cf to avoid > attempts to login to my smtpd. smtpd_reject_unlisted_sender does not prevent logins. > This morning it looks like an unknown ip-number succeded: > > Jun 23 07:38:02 lunar postfix/smtpd[14806]: connect from > unknown[185.137.111.22] > Jun 23 07:38:05 lunar amavis[15407]: starting. /usr/sbin/amavisd-new at > lunar.dk amavisd-new-2.10.1 (20141025), Unicode aware, LC_ALL="C", > LANG="en_US.UTF-8" There is no evidence of a login from 185.137.111.22. Wietse
Re: dkim updating keys
* Lefteris Tsintjelis: > There is nothing to disappear from cache for the new key. Lefteris, I am fully aware. As I wrote, I don't trust every caching resolver out there to do the right thing (meaning to query for new information while older data is still in the cache). It should happen, but I rather wait an extra day. You may of course make your own choice, it makes no difference to me. -Ralph
Re: havedane dns issues
> I just sent an email via the contact form. Thanks! > 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. Yes, I now also disabled it. - tmolitor
Re: dkim updating keys
On 23/6/2019 23:25, Ralph Seichter wrote: * Lefteris Tsintjelis: In case DNS does not use notify then yes you should wait for the zone refresh time in SOA (not TTL) for all slaves to sync. I recommended the zone's TTL because it is the upper limit for all cached data to disappear There is nothing to disappear from cache for the new key. This is a new selector so all is needed is for all DNS servers to be in sync (notify takes care of that) and that is all. You may start using it. Lefteris
Smptd intruder
Hi I introduced "smtpd_reject_unlisted_sender=yes" in main.cf to avoid attempts to login to my smtpd. This morning it looks like an unknown ip-number succeded: Jun 23 07:38:02 lunar postfix/smtpd[14806]: connect from unknown[185.137.111.22] Jun 23 07:38:05 lunar amavis[15407]: starting. /usr/sbin/amavisd-new at lunar.dk amavisd-new-2.10.1 (20141025), Unicode aware, LC_ALL="C", LANG="en_US.UTF-8" Jun 23 07:38:06 lunar amavis[15412]: Net::Server: Group Not Defined. Defaulting to EGID '121 121' Jun 23 07:38:06 lunar amavis[15412]: Net::Server: User Not Defined. Defaulting to EUID '114' How can I avoid this acitivty. Thanks in advance
Re: dkim updating keys
* Lefteris Tsintjelis: > In case DNS does not use notify then yes you should wait for the zone > refresh time in SOA (not TTL) for all slaves to sync. I recommended the zone's TTL because it is the upper limit for all cached data to disappear, but yes, data newly added to the zone should usually be available sooner. My own DNS pair will deliver additions within seconds after I make the change, but I don't quite trust every caching resolver out there and rather wait an extra day. -Ralph
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.
On 24/06/19 3:38 AM, Chris Pollock wrote: I still have some that are going to /var/spool/mail/nobody however. Headers below: And your logs show what exactly? Peter
Re: Greylisting -- current recommendations?
On 24/06/19 5:21 AM, A. Schulze wrote: while running postscreen and postgrey I still see some connections deferred by postgrey... no more details available on a sunday. If you're running the after-220 tests in postscreen then these messages are actually deferring twice, and the fact that postgrey defers does not mean it caught spam, it means it may be spam and it is delaying the message further to try to check. If postscreen is catching the vast majority of these then all you're seeing is unnecessary delay on legitimate mail. Peter
Re: Greylisting -- current recommendations?
On 22/06/19 12:49 PM, Rich Wales wrote: I'm running Postfix 3.1.0 on an Ubuntu 16.04 LTS system. II'm using Postfix's postscreen filtering, including zen.spamhaus.org (with a large score) as one of my DNSBL sites, but it's not helping in some cases because the spam sources are not showing up on Spamhaus at the time I get e-mail from them -- only later on. I'm wondering if it may be worthwhile for me to enable greylisting in some form on my server. I'm aware of Postgrey, but I'm uneasy because this package seems to get updated so rarely (the latest version is about three years old). Just enable (and use) the after-220 tests for postscreen which have basically the same effect as greylisting. Postscreen with the after-220 tests enabled basically makes postgrey obsolete. See http://rob0.nodns4.us/postscreen.html which uses dnswl scoring to address some of the issues with major ESPs such as google and the after-220 tests. Peter
Re: dkim updating keys
On 23/6/2019 16:20, Ralph Seichter wrote: * Esteban L.: Trying to figure this out with as little disruption as possible. I sugest you do the following, in order: * Generate new key. * Add new key's data, using a new DKIM selector, to your DNS. * Wait for your domain zone's DNS TTL to expire (typically 1-2 days). Yes that is the way. One detail here. In case DNS does not use notify then yes you should wait for the zone refresh time in SOA (not TTL) for all slaves to sync. Just about any DNS now days uses notify and the new DKIM selector should be available within seconds after the zone reload in all authoritative domain servers, if all set correctly and you could use your new key almost immediately, if you control the reload time. In any case, you can easily and should verify that with a dig or an nslookup. Lefteris * Switch to signing with the new key. * Wait another 1-2 days, in case messages signed with the previous key are still in limbo somewhere (low risk of that, but still). * Remove old key's data from DNS. > As long as you make sure to use a different DKIM selector for each key, that should suffice for a key rollover. -Ralph
Re: dkim updating keys
Thanks Ralph. That was the step-by-step guide I was looking for. The simplest things are always the hardest to find information for. Esteban -- https://little-beak.com "Doing what we can." -Original Message- From: Ralph Seichter To: postfix-users@postfix.org Subject: Re: dkim updating keys Date: Sun, 23 Jun 2019 15:20:42 +0200 * Esteban L.: > Trying to figure this out with as little disruption as possible. I sugest you do the following, in order: * Generate new key. * Add new key's data, using a new DKIM selector, to your DNS. * Wait for your domain zone's DNS TTL to expire (typically 1-2 days). * Switch to signing with the new key. * Wait another 1-2 days, in case messages signed with the previous key are still in limbo somewhere (low risk of that, but still). * Remove old key's data from DNS. As long as you make sure to use a different DKIM selector for each key, that should suffice for a key rollover. -Ralph signature.asc Description: This is a digitally signed message part
Re: Greylisting -- current recommendations?
I'm using conditional greylisting with policy-weightd and postgrey. And another conditional greylisting if the spamassassin score is too high using milter-greylist. This doesn't introduce delays for most of the incoming mails but penalizes zombies / mailservers with strange behaviours :) - tmolitor Am Sonntag, 23. Juni 2019, 13:24:59 CEST schrieb Wietse Venema: > Matus UHLAR - fantomas: > > >Am 22.06.19 um 02:49 schrieb Rich Wales: > > >> Any other suggestions? > > > > On 22.06.19 14:43, A. Schulze wrote: > > >I'm still using greylisting with moderate effects. It catches some > > >percent other AntiSpam technics doesn't> > > even compared to postscreen? > > I would expect that greylisting blocks some spambots before they > are blacklisted in DNSBLs. > > Wietse
Re: TLS 1.3 on postfix (fixed)
" Whatever the default, the logs you posted showed TLS 1.3" I have noticed that some gmail comes through as TLS 1.2 and some as TLS 1.3; I am guessing that not all of Google's SMTP gateways are TLS 1.3 yet... On 6/22/19, 2:13 PM, "owner-postfix-us...@postfix.org on behalf of Viktor Dukhovni" wrote: > 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.
Re: Greylisting -- current recommendations?
Matus UHLAR - fantomas: > >Am 22.06.19 um 02:49 schrieb Rich Wales: > >> Any other suggestions? > > On 22.06.19 14:43, A. Schulze wrote: > >I'm still using greylisting with moderate effects. It catches some percent > >other AntiSpam technics doesn't > > even compared to postscreen? I would expect that greylisting blocks some spambots before they are blacklisted in DNSBLs. Wietse
Re: Greylisting -- current recommendations?
Am 23.06.19 um 16:57 schrieb Matus UHLAR - fantomas: > On 22.06.19 14:43, A. Schulze wrote: >> I'm still using greylisting with moderate effects. It catches some percent >> other AntiSpam technics doesn't > > even compared to postscreen? yes while running postscreen and postgrey I still see some connections deferred by postgrey... no more details available on a sunday. Andreas
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.
Chris Pollock: > On Sun, 2019-06-23 at 01:21 -0400, Viktor Dukhovni wrote: > > 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. > > Thank you for the reply Viktor. I've finally got it partially working > with my GMail account now and most of my cronjob messages are being > sent and returned to me as before. By adding the [ ] around the > smtp.gmail.com it started working. > I still have some that are going to /var/spool/mail/nobody however. > Headers below: > > From chris.pollock1...@gmail.com Sun Jun 23 09:01:26 2019 > Return-Path: > X-Original-To: root All mail for root goes to nobody, if you're delivering mail with procmail or the like. Postfix expects that UNIX systems are used according this best practice: - Log in as a real user, not as root. - Use su (or sudo) for doing root stuff. - Set up an alias root-> real user, and read mail as the real user. 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.
On Sun, 2019-06-23 at 01:21 -0400, Viktor Dukhovni wrote: > 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. Thank you for the reply Viktor. I've finally got it partially working with my GMail account now and most of my cronjob messages are being sent and returned to me as before. By adding the [ ] around the smtp.gmail.com it started working. I still have some that are going to /var/spool/mail/nobody however. Headers below: From chris.pollock1...@gmail.com Sun Jun 23 09:01:26 2019 Return-Path: X-Original-To: root Delivered-To: root@cpollock.localdomain Received: by cpollock.localdomain (Postfix, from userid 0) id 3A4991000E12; Sun, 23 Jun 2019 09:01:25 -0500 (CDT) From: chris.pollock1...@gmail.com (Cron Daemon) To: root@cpollock.localdomain Though in my aliases file I have root set: # Person who should get root's mail. This alias # must exist. # CHANGE THIS LINE to an account of a HUMAN root: chris.pollock1...@gmail.com I'm sure it's something simple and I'll just have to read and reread until I get it figured out. It was working well under my ISP until they decided to start doing something to some of my outgoing cron messages where they weren't being returned and some even marked as spam. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 09:08:27 up 2 days, 15:18, 1 user, load average: 0.67, 0.95, 0.95 Description:Ubuntu 18.04.2 LTS, kernel 4.18.0-22-generic signature.asc Description: This is a digitally signed message part
Re: Unable to send or receive from Gmail
On 22.06.19 15:03, 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). have you tried to enforce tls1.3? Lower TLS version should be negotiated if 1.3 negiotiation doesn't succeed. What are your tls-related options? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "Where do you want to go to die?" [Microsoft]
Re: Greylisting -- current recommendations?
Am 22.06.19 um 02:49 schrieb Rich Wales: Any other suggestions? On 22.06.19 14:43, A. Schulze wrote: I'm still using greylisting with moderate effects. It catches some percent other AntiSpam technics doesn't even compared to postscreen? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "The box said 'Requires Windows 95 or better', so I bought a Macintosh".
Re: dkim updating keys
* Esteban L.: > Trying to figure this out with as little disruption as possible. I sugest you do the following, in order: * Generate new key. * Add new key's data, using a new DKIM selector, to your DNS. * Wait for your domain zone's DNS TTL to expire (typically 1-2 days). * Switch to signing with the new key. * Wait another 1-2 days, in case messages signed with the previous key are still in limbo somewhere (low risk of that, but still). * Remove old key's data from DNS. As long as you make sure to use a different DKIM selector for each key, that should suffice for a key rollover. -Ralph
dkim updating keys
Friendly Greetings, I am going to update my email server's Dkim keys for the first time. I can go to the original install instructions, and figure out how to update them. What I can't find in that original tutorial is the following: 1. Do I delete/remove old key and references thereto? Namely, in the key.table? 2. Do I just create the new key, and update the key.table, and upload the txt to my DNS? 3. Do I leave my old key information (including on the DNS) for a "grace period" of a week or so? Trying to figure this out with as little disruption as possible. Thanks in advance. Esteban -- https://little-beak.com "Doing what we can."
