Topic: [SOLVED] Easy configuration to talk to other SMTP servers securely?

[Michail Pappas]

Not an expert here, so I might not be phrasing things quite well.

In any case, and if I understand correctly, communication between mail servers may be in secure SMTP form. Can 9.1 do it?

I am asking here because Google has started showing a small red unlocked lock key when communication came from a party without some form of encryption. I think this is a new feature and, in my server's case, communication seems to be in not encrypted form.

Can I easily switch to encrypted communication during server-to-server SMTP transfers (or show that my sme is willing to proceed in an encrypted manner)?

[DanB35]

Not an immediate answer, but here's a Google page with a little more detail about what they're looking for: https://support.google.com/mail/answer/180707?hl=en

It looks like it relies on DKIM and SPF.  Here's some information on setting up DKIM with SME: https://wiki.contribs.org/Email#DKIM_Setup.  I don't immediately see information on implementing SPF, but I'll check some more.

[Michail Pappas]

Thanks, however if I understand correctly both of these links include information to strongly identify whether the sender of an incoming email is spoofed or not.

What I am looking for is means to configure SME, so that when talking to another, encryption-willing mail server, the SMTP session will be encrypted. End-to-end encryption that is.

[DanB35]

What I am looking for is means to configure SME, so that when talking to another, encryption-willing mail server, the SMTP session will be encrypted. End-to-end encryption that is.

SME already does this via STARTTLS.  But according to Google's docs, from what I can see, the red padlock icon is not related to in-transit encryption, but to sender authentication (DKIM/SPF).  Do you have something from Google that says otherwise?

Edit: Never mind, looks like you're talking about this: https://support.google.com/mail/answer/6330403?hl=en.  I was confusing the red question mark (which is clickable, and explains what it means) with the red padlock (which isn't clickable).  Thanks, Google, for making things a bit confusing...

I stand by my statement above that SME does SMTP over TLS, but it appears it isn't using TLS (at least) when talking with the gmail servers.  I don't know why that would be--perhaps some research will help.

[CharlieBrady]

I stand by my statement above that SME does SMTP over TLS,...

... only when transferring messages to a configured SmartHost. When there is no SmartHost configured, qmail-remote does deliveries over port 25, unencrypted, based on MX or A records for the destination mail server.

[DanB35]

Thanks for the clarification.  Is there a way to change this?  It seems a sensible default would be to attempt to use TLS when connecting to any remote host.

[CharlieBrady]

Thanks for the clarification.  Is there a way to change this?

Modify qmail, or use a different MTA. There might be patches for qmail which other people have already made.

It seems a sensible default would be to attempt to use TLS when connecting to any remote host.

What do you do when the cert has problems, e.g. weak ciphers, wrong name or unknown signing cert?

[byte]

I wouldn't personally worry too much about this, just Google decided to show an icon that the message is encrypted or not, until Google decided to "show" an padlock icon we never "knew" about this.

As long as you've set up your MX / SPF etc, correctly everything will be fine.

If you are really paranoid about privacy etc, then use something like Proton Mail

[DanB35]

What do you do when the cert has problems, e.g. weak ciphers, wrong name or unknown signing cert?

I'd think that should be configurable by the server admin, on a couple of levels: (1) what features are required for TLS to work (hostname match, recognized cert, which ciphers), with sensible defaults; and (2) what to do of TLS fails (send in cleartext, refuse to send, or ???).  On the second point, I'd think a fallback to cleartext would be a reasonable default--try to transport via TLS if possible, but use cleartext if not.

But if the only way to make qmail do this is to patch it, or otherwise use a different MTA, it would appear that the answer to Michail's question is that there's no easy way to do this.

[CharlieBrady]

it would appear that the answer to Michail's question is that there's no easy way to do this.

Use a SmartHost. IOW, delegate.

[Michail Pappas]

From the sound of it, it's not an easy feat to accomplish. At least for someone with my rather low knowledge of this area...

I have SPF installed, and there's an excellent DKIM setup page in the wiki, so I'll most likely tackle that.

Thanks to all for your feedback, I certainly got a quite interesting read queue waiting for me