I turned on opportunistic TLS last summer I think. All was fine for a
long time. btw - I'm currently running the FreeBSD
postfix-current-3.0.20151003,4 port but previously used 2.8.
Somewhat recently someone with a residential cable provider account
complained that he got mail from me but mail from him to me bounced
(soft, so repeated bounce messages). I was still getting email from
everywhere else, gmail, verizon, corporations, universities, IETF,
lots of places, just no mail from that cable provider and only
recently. This was with no significant change on my end on the
primary MX and none at all on the secondary MX.
A cable provider is using a useful new SMTP feature. Can't complain
about that. It would be nice if it didn't dump mail on the floor.
The logs revealed something about the nature of the problem. A few of
these sort of messages were found.
Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
warning: TLS library problem:
error:1408A0C1:SSL
routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1411:
Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
lost connection after STARTTLS
from resqmta-po-05v.sys.comcast.net[2001:558:fe16:19:96:114:154:164]
The workaround is change may to none:
smtpd_tls_security_level = none
What I'd like to do is set smtpd_tls_security_level back to "may" and
then somehow set it to "none" if the EHLO domain is comcast.net (oops
the secret is out).
I see we have smtp_tls_policy_maps, but no smtpd_tls_policy_maps.
It seems the place in the code to hook that in would be near where the
smtpd_helo_restrictions get checked.
It would also be nice to have the smptd rough equivalent of
smtp_tls_note_starttls_offer to see when TLS was used and OK if
"smtpd_tls_loglevel = 0" is used, though "smtpd_tls_loglevel = 1" is
close but a bit more verbose than just knowing it was OK.
I think the problem is that All my keys are EC generated using openssl
1.0.2, which was a brand spanking new release in Jan 2015 (yes, last
year, not this year) and comcast recently enable opportunistic TLS but
is using a release that is a year older or more - 1.0.1 or prior.
OTOH- It could also be:
smtpd_tls_mandatory_ciphers = high
Haven't tried cranking back on that. Could it be that they compiled
out everything but the fairly weak "medium" ciphers? Anyone know?
In any case I figured out a way to get more information. It seems
rather than fall back and use unencrypted, the fallback is to the
secondary MX record.
So now I have "smtpd_tls_security_level = may" and debugging turned
way up for comcast.net on the primary MX and and no debugging but
"smtpd_tls_security_level = none" on the backup MX. I should get
debugging and a failure on the primary and delivery of mail on the
secondary so no bounced mail.
btw- that wasn't a request to send me a test message. I'll send to my
friend and ask for a reply if nothing arrives in the next few hours.
Any suggestions? Any insights on this problem?
Curtis
ps - Somewhere in comcast someone is sitting back happy that they
deployed something new and nothing bad happenned (between them and the
other big guys anyway). Oh well.
