Re: Postfix is not open relay but send spam
Or use openssl s_client -starttls smtp -connect :25 for tls on port 25 (in case port 465 is not configured on your server or the configuration differs from port 25) Am Dienstag, 15. Oktober 2019, 11:30:42 CEST schrieb Bill Cole: > On 15 Oct 2019, at 11:15, Julien Michaux wrote: > > Do you have a way to test authentification with smtps ? > > openssl s_client -connect :465 > > That will negotiate an SSL/TLS connection with the given host on port > 465 (smtps) and leave you inside the encrypted session as if you'd used > 'telnet :25'
Re: Trying to understand error message in logs
...and check permissions on *all* the directories in the path leading to the
lockfile for proper access (at least eXecute permission) and no conflicting
ACLs
(as viktor already wrote).
--tmolitor
Am Freitag, 11. Oktober 2019, 15:00:36 CEST schrieb Viktor Dukhovni:
> Reboot your system, and try again.
>
> > On Oct 11, 2019, at 2:49 PM, Fazzina, Angelo
> > wrote:
> >
> > Hi, thanks for the tip about checking SELINUX. Sadly no change when
> > testing openssl command with SELINUX off.
> TLS has nothing to with this. The SMTP server is unable to
> lock a file that is used to avoid waking up all the SMTP
> listeners every time a new connection arrives. The lock
> file ensures that only listener is waiting to accept new
> connections at a time.
>
> The EPERM error is not normal in this context. On my
> system:
>
> $ ls -ld /var/spool/postfix{,/pid{,/inet.smtp}}
> drwxr-xr-x 16 root wheel16 Aug 4 22:46 /var/spool/postfix
> drwxr-xr-x 2 root postfix 19 Apr 18 04:43 /var/spool/postfix/pid
> -rw--- 1 root postfix 0 Feb 19 2017
> /var/spool/postfix/pid/inet.smtp
>
> which shows that only root can open the lock file, and yet
> there are no issues with the lock, because Postfix opens
> the file before dropping privs. So if you're seeing EPERM,
> your system is either configured with additional security
> restrictions, or has become confused and needs a reboot.
>
> Also, make sure there are no additional extended ACLs on the file,
> immutable bits, ... Good luck.
>
> Don't waste time with TLS, that's entirely irrelevant.
Re: Specifying certificates in master.cf
Letsencrypt *never* generates keys for you. He talked about the lezsencrypt client he uses, which generates a key locally, submits a CSR to letsencrypt and provides 2 files (the generated key and the obtained certificate) afterwards. Am 2. Oktober 2019 04:25:44 MESZ schrieb Olivier : >Viktor Dukhovni writes: > >>> On Oct 1, 2019, at 12:39 PM, linkcheck >wrote: >>> >>> Letsencrypt supplies 2 files. I don't think it combines them inso a >single >>> one, though I may be wrong. I know it's possible to combine them on >the >>> server but the auto-update of the cert then becomes complicated. >> >> That's mostly OK. You can use two files if you wish, there's a tiny >> chance of a Postfix SMTP server reading a mismatched pair of key and >> cert during a rollover, if you're changing both the cert and the key. >> >> This can be avoided by staging a single file with both, which is >> verified to have a matching key and cert before it atomically >> replaces the live Postfix key + cert file. > >But why letting let's Encrypt generate your key file? > >Generate your own key file, so you can be sure that the private key has >never been seen by anymody. > >Generate your csr and use that csr to have it signed by Let's Encrypt. > >That way, you only get one certificate file to install, no risk of >atomic race gap. > >The key and csr can be reused as much as you like, they don't expire >unless you want to do so, so it is 10 minutes well used. > >Possibly, I check about it, but I haven't yet faced the case since I >use >let's Encrypt, the intermediate ca could change, but in that case, >having your own key or a key provided by ;let's Encrypt woul dnot >change >anything to the proble, you'd have to reinstall the new intermediate >ca, >with a possible race condition in the mean time. > >Best regards, > >Olivier >--
Re: Error 46 with TLS
Do you know what client sends the alert? Maybe it is misconfigured... Am 21. September 2019 21:26:14 MESZ schrieb "@lbutlr" : >On Sep 21, 2019, at 12:17 PM, Dominic Raferd >wrote: >> smtpd_tls_cert_file = >/etc/letsencrypt/live/streamingbats.co.uk/fullchain.pem >> smtpd_tls_key_file = >/etc/letsencrypt/live/streamingbats.co.uk/privkey.pem >> >> Should I be setting any other parameters? > >That works here. > > > >-- >"You never really understand a person until you see things from his >point of view, until you climb inside of his skin and walk around in >it.”
Re: SSL communication between MTAs
MTA-STS is not the only technique, DANE (rfc7672) can be used, too (and in fact it is by many big german providers at least). See this slides for an introduction: https://www.netnod.se/sites/default/files/ 2016-12/Anders_Berggren_can_haz_secure_mail.pdf Or this wikipedia page: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Email_encryption - Thilo Am Donnerstag, 15. August 2019, 10:44:16 CEST schrieb a: > You can't enforce remote peer to use SSL unless that peer is under your > control. > > Maximum that you can do - enable STARTTLS and configure MTA-STS (rfc8461). > > чт, 15 авг. 2019 г., 9:53 Eliza : > > Hello, > > > > My MTA (postfix) has both 25 (non-SSL) and 465 (SSL) ports enabled. > > > > How to enforce the peer MTA send messages only to 465 port for better > > secure communication? > > > > Can I just shutdown port 25? > > > > Thanks.
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: 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
havedane dns issues
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: Block spam at smtp time, but then still forward to users spam box
> I would never do this. My rule is very simple, anything we accept gets > delivered to the user. Anything we reject gets rejected during the SMTP > transaction. If it is LEGITIMATE mail, the sender will see the rejection. This simple rule ensures a timely notification of the sender if something is wrong and I implement it like this, too. @Brent: If your users never (or very seldom) look into the spam folder or periodically clear it without manually sorting it, all legitimate mail in the spam folder will get lost without sender and recipient ever noticing. If no spam folder is used but rejects, the sender will get notified and can try to reach the recipient via some other communication channel. At least in germany this has legal implications, too. See for example this presenation (in german, sorry folks): https://www.heinlein-support.de/vortrag/spam-quarantaene-und-tagging-der-grosse-irrtum Am Montag, 20. Mai 2019, 12:53:34 CEST schrieb @lbutlr: > On 20 May 2019, at 01:42, Brent Clark wrote: > > My colleague has proposed that at smtp time, if a mail is deemed as spam, > > the server issues a reject code, but then to too accept the mail and > > forward the mail the user for incase its a false positive. > The odds of a mail scoring over 10.0 on SpamAssassin being legit are so low > as to be meaningless, so that's a silly reason to implement a completely > non-standard email chain that is likely to only anger your users with even > more spam to sort through. > > His logic is that, that the spammer does not build up a database. > > The days of that are long past. Spammers simply buy lists of billions of > emails. They do not care about delivery at all. > > Currently what we do is, if the score is between 5 and 15, just accept and > > move the spam to the users SPAM box. Above 15 we out right block. > I'd say 15 is far too high and including that much spam probably trains your > users to never even bother looking at the spam folder, but that's fine. > > I am on the fence on this one, hence the reason to pick the communities > > brain. > I would never do this. My rule is very simple, anything we accept gets > delivered to the user. Anything we reject gets rejected during the SMTP > transaction. If it is LEGITIMATE mail, the sender will see the rejection.
