On Sat, Feb 06, 2021 at 12:05:44PM +0100, OzyMate wrote:
> I am trying to setup my postfix (on CentOS 8) to work with Amazon SES as
> SMTP relay host.
Will this be a relay for *all* or just some outbound email?
I'll assume *all* for now.
> Amazon SES requires:
>
> relayhost = [email-smtp.eu-west-2.amazonaws.com]:587
> smtp_sasl_auth_enable = yes
> smtp_sasl_security_options = noanonymous
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_use_tls = yes
> smtp_tls_security_level = encrypt
> smtp_tls_note_starttls_offer = yes
These settings are too global and somewhat sloppy, better would be to
narrow their scope to a single (default) transport and fix the slop
(wrong security level, obsolete "use_tls", and pointless
"note_starttls_offer"):
main.cf:
default_transport = submit:[email-smtp.eu-west-2.amazonaws.com]:587
submit_tls_security_level = secure
submit_sasl_auth_enable = yes
submit_sasl_security_options = noanonymous
submit_sasl_password_maps = hash:/etc/postfix/sasl_passwd
# Adjust to a CA store that includes any root CA certs
# that are needed and trusted to authenticate amazon.
# See below...
submit_tls_CAfile = /etc/ssl/cert.pem
master.cf:
submit unix - - n - - smtp
-o smtp_tls_security_level=$submit_tls_security_level
-o smtp_sasl_auth_enable=$submit_sasl_auth_enable
-o smtp_sasl_security_options=$submit_sasl_security_options
-o smtp_sasl_password_maps=$submit_sasl_password_maps
The root CA store should include at least one of the CA certs below,
of which any one (most efficiently the first) is sufficient to verify
the current Amazon certificate chain. However, they could switch
to a different CA hierarchy at some future time, so a somewhat larger
list of trusted CAs may be appropriate. Perhaps they document which
one's they expect to use, but otherwise you may need to trust a few
more of "the usual suspects":
serial=066C9FCF99BF8C0A39E2F0788A43E696365BCA
subject=C = US, O = Amazon, CN = Amazon Root CA 1
issuer=C = US, O = Amazon, CN = Amazon Root CA 1
notBefore=May 26 00:00:00 2015 GMT
notAfter=Jan 17 00:00:00 2038 GMT
SHA1 Fingerprint=8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16
-----BEGIN CERTIFICATE-----
MIIDQTCCAimgAwIBAgITBmyfz5m/jAo54vB4ikPmljZbyjANBgkqhkiG9w0BAQsF
ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6
b24gUm9vdCBDQSAxMB4XDTE1MDUyNjAwMDAwMFoXDTM4MDExNzAwMDAwMFowOTEL
MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJv
b3QgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJ4gHHKeNXj
ca9HgFB0fW7Y14h29Jlo91ghYPl0hAEvrAIthtOgQ3pOsqTQNroBvo3bSMgHFzZM
9O6II8c+6zf1tRn4SWiw3te5djgdYZ6k/oI2peVKVuRF4fn9tBb6dNqcmzU5L/qw
IFAGbHrQgLKm+a/sRxmPUDgH3KKHOVj4utWp+UhnMJbulHheb4mjUcAwhmahRWa6
VOujw5H5SNz/0egwLX0tdHA114gk957EWW67c4cX8jJGKLhD+rcdqsq08p8kDi1L
93FcXmn/6pUCyziKrlA4b9v7LWIbxcceVOF34GfID5yHI9Y/QCB/IIDEgEw+OyQm
jgSubJrIqg0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0OBBYEFIQYzIU07LwMlJQuCFmcx7IQTgoIMA0GCSqGSIb3DQEBCwUA
A4IBAQCY8jdaQZChGsV2USggNiMOruYou6r4lK5IpDB/G/wkjUu0yKGX9rbxenDI
U5PMCCjjmCXPI6T53iHTfIUJrU6adTrCC2qJeHZERxhlbI1Bjjt/msv0tadQ1wUs
N+gDS63pYaACbvXy8MWy7Vu33PqUXHeeE6V/Uq2V8viTO96LXFvKWlJbYK8U90vv
o/ufQJVtMVT8QtPHRh8jrdkPSHCa2XV4cdFyQzR1bldZwgJcJmApzyMZFo6IQ6XU
5MsI+yMRQ+hDKXJioaldXgjUkK642M4UwtBV8ob2xJNDd2ZhwLnoQdeXeGADbkpy
rqXRfboQnoZsG4q5WTP468SQvvG5
-----END CERTIFICATE-----
serial=00
subject=C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies,
Inc.", CN = Starfield Services Root Certificate Authority - G2
issuer=C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies,
Inc.", CN = Starfield Services Root Certificate Authority - G2
notBefore=Sep 1 00:00:00 2009 GMT
notAfter=Dec 31 23:59:59 2037 GMT
SHA1 Fingerprint=92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63:E8:25:6F:3F
-----BEGIN CERTIFICATE-----
MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT
HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs
ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTA5
MDkwMTAwMDAwMFoXDTM3MTIzMTIzNTk1OVowgZgxCzAJBgNVBAYTAlVTMRAwDgYD
VQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMSUwIwYDVQQKExxTdGFy
ZmllbGQgVGVjaG5vbG9naWVzLCBJbmMuMTswOQYDVQQDEzJTdGFyZmllbGQgU2Vy
dmljZXMgUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgLSBHMjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANUMOsQq+U7i9b4Zl1+OiFOxHz/Lz58gE20p
OsgPfTz3a3Y4Y9k2YKibXlwAgLIvWX/2h/klQ4bnaRtSmpDhcePYLQ1Ob/bISdm2
8xpWriu2dBTrz/sm4xq6HZYuajtYlIlHVv8loJNwU4PahHQUw2eeBGg6345AWh1K
Ts9DkTvnVtYAcMtS7nt9rjrnvDH5RfbCYM8TWQIrgMw0R9+53pBlbQLPLJGmpufe
hRhJfGZOozptqbXuNC66DQO4M99H67FrjSXZm86B0UVGMpZwh94CDklDhbZsc7tk
6mFBrMnUVN+HL8cisibMn1lUaJ/8viovxFUcdUBgF4UCVTmLfwUCAwEAAaNCMEAw
DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJxfAN+q
AdcwKziIorhtSpzyEZGDMA0GCSqGSIb3DQEBCwUAA4IBAQBLNqaEd2ndOxmfZyMI
bw5hyf2E3F/YNoHN2BtBLZ9g3ccaaNnRbobhiCPPE95Dz+I0swSdHynVv/heyNXB
ve6SbzJ08pGCL72CQnqtKrcgfU28elUSwhXqvfdqlS5sdJ/PHLTyxQGjhdByPq1z
qwubdQxtRbeOlKyWN7Wg0I8VRw7j6IPdj/3vQQF3zCepYoUz8jcI73HPdwbeyBkd
iEDPfUYd/x7H4c7/I9vG+o1VTqkC50cRRj70/b17KSa7qWFiNyi2LSr2EIZkyXCn
0q23KXB56jzaYyWf/Wi3MOxw+3WKt21gZ7IeyLnp2KhvAotnDU0mV3HaIPzBSlCN
sSi6
-----END CERTIFICATE-----
serial=00
subject=C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2
Certification Authority
issuer=C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2
Certification Authority
notBefore=Jun 29 17:39:16 2004 GMT
notAfter=Jun 29 17:39:16 2034 GMT
SHA1 Fingerprint=AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
-----BEGIN CERTIFICATE-----
MIIEDzCCAvegAwIBAgIBADANBgkqhkiG9w0BAQUFADBoMQswCQYDVQQGEwJVUzEl
MCMGA1UEChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMp
U3RhcmZpZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDQw
NjI5MTczOTE2WhcNMzQwNjI5MTczOTE2WjBoMQswCQYDVQQGEwJVUzElMCMGA1UE
ChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMpU3RhcmZp
ZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3
DQEBAQUAA4IBDQAwggEIAoIBAQC3Msj+6XGmBIWtDBFk385N78gDGIc/oav7PKaf
8MOh2tTYbitTkPskpD6E8J7oX+zlJ0T1KKY/e97gKvDIr1MvnsoFAZMej2YcOadN
+lq2cwQlZut3f+dZxkqZJRRU6ybH838Z1TBwj6+wRir/resp7defqgSHo9T5iaU0
X9tDkYI22WY8sbi5gv2cOj4QyDvvBmVmepsZGD3/cVE8MC5fvj13c7JdBmzDI1aa
K4UmkhynArPkPw2vCHmCuDY96pzTNbO8acr1zJ3o/WSNF4Azbl5KXZnJHoe0nRrA
1W4TNSNe35tfPe/W93bC6j67eA0cQmdrBNj41tpvi/JEoAGrAgEDo4HFMIHCMB0G
A1UdDgQWBBS/X7fRzt0fhvRbVazc1xDCDqmI5zCBkgYDVR0jBIGKMIGHgBS/X7fR
zt0fhvRbVazc1xDCDqmI56FspGowaDELMAkGA1UEBhMCVVMxJTAjBgNVBAoTHFN0
YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xMjAwBgNVBAsTKVN0YXJmaWVsZCBD
bGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8w
DQYJKoZIhvcNAQEFBQADggEBAAWdP4id0ckaVaGsafPzWdqbAYcaT1epoXkJKtv3
L7IezMdeatiDh6GX70k1PncGQVhiv45YuApnP+yz3SFmH8lU+nLMPUxA2IGvd56D
eruix/U0F47ZEUD0/CwqTRV/p2JdLiXTAAsgGh1o+Re49L2L7ShZ3U0WixeDyLJl
xy16paq8U4Zt3VekyvggQQto8PT7dL5WXXp59fkdheMtlb71cZBDzI0fmgAKhynp
VSJYACPq4xJDKVtHCN2MQWplBqjlIapBtJUhlbl90TSrE9atvNziPTnNvT51cKEY
WQPJIrSPnNVeKtelttQKbfi3QBFGmh95DmK/D5fs4C8fF5Q=
-----END CERTIFICATE-----
> If I use the above lines in main.cf, mails are not delivered with the
> following error in logs:
>
> TLS is required, but was not offered by host 127.0.0.1
Probably because you're also using an SMTP content_filter which
is affected by the global "smtp_tls" settings.
On Sat, Feb 06, 2021 at 12:23:27PM +0100, Bastian Blank wrote:
> Maybe because "may" does exactly what it say?
But in fact for submission via a password one should use "secure"
not "may" or "encrypt".
On Sat, Feb 06, 2021 at 02:15:01PM -0500, Bill Cole wrote:
> > TLS is required, but was not offered by host 127.0.0.1
>
> Why are you routing mail via SMTP over the loopback and requiring
> encryption?
Inadvertently of course, the former, presumably for a content_filter,
and the latter intended just for the final hop...
> See http://www.postfix.org/DEBUG_README.html#mail, the section on how to
> effectively get help here by providing useful information.
Indeed a more complete configuration dump would better tell the story.
> > I would appreciate any insight to fix this problem. Also, is
> > "smtp_tls_security_level = may" a security problem?
>
> Not necessarily. If you don't distrust your own machine, and can be sure
> that Amazon SES will always offer STARTTLS, it is harmless. The most
> direct fix is to make sure that you have smtpd_* settings that will
> allow you to offer STARTTLS on the smtpd instance handling initial
> submission on the loopback. Depending on how you're already set up and
> what you need Postfix to do beyond sending out email, there may be a
> more fit solution.
No, there's no need to do TLS on the loopback interface, rather TLS
should be just on the outbound hop, and there it should be not only
required, but also *authenticated*.
--
Viktor.
