in
postconf mail_version
mail_version = 3.8.1
i just caught the following TLS error in postfix logs,
2023-08-12T09:33:07.064713-04:00 cmx0024 postfix/postscreen[27816]:
cache lmdb:/var/lib/postfix/postscreen_cache full cleanup: retained=0 dropped=0
entries
why?
not my own server/config
Can you explain how each of these is better than the Postfix defaults?
all but two _are_ at defaults
postconf -n | grep -i tls | grep -i cipher | sort
@D smtpd_tls_ciphers = medium
@D smtpd_tls_exclude_ciphers =
@D
As background, the RELEASE_NOTES for 3.8 mention:...>>
postfix/psint/smtpd[27820]:
esa.hc2802-61.iphmx.com[139.138.32.157]: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:!SEED:!IDEA:!3DES:!RC2:!RC4:!RC5:!kDH:!kECDH:!aDSS:!MD5:+RC4:@STRENGTH:!aNULL"
yep
Which is most of the above, but you
one'd hope that banks and hospitals might be a bit more up-to-date on their end.
after the key file cleanup,
...
Untrusted TLS connection established from
esa.hc2802-61.iphmx.com[68.232.155.227]: TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256
...
seems, in fact, EC-ready
That'd then be the file to analyse:
# tshark -nr /tmp/tls.pcap -V ssl
thx for the ez tutorial
after the key file cleanup,
...
Untrusted TLS connection established from
esa.hc2802-61.iphmx.com[68.232.155.227]: TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256
...
This explain
Consider (after carefully reading over the docs explaining the required
ordering of the content) switching to consolidated preferred syntax:
smtpd_tls_chain_files =
>> This feature is available in Postfix 3.4 and later.
that one snuck by me :-/
convenient, tho, thx!
No tool. J
my "BFFs" @ M$'s *.outlook.com have decided over the last month or so to send
many 10K's of these
2023-08-14T13:11:53.782611-04:00 svr01 postfix/postscreen[27910]:
CONNECT from [52.101.56.17]:32607 to [209.123.234.54]:25
2023-08-14T13:11:59.860098-04:00 svr01 postfix/postscreen[
There is no protection you can add to prevent this
fair enuf
other than firewalling them completely.
the wishful-thinking of fw'ing MS's entire ASN has crossed my mind more than
once ;-)
Why do they do this? Only they know.
if they do, they certainly don't respond to @support/etc inqui
OK mail from outlook does make it's way thru; e.g., since Monday,
xzegrep "250 2.0.0 Queued as.*outbound.protection.outlook.com"
/var/log/postfix/postfix.log | wc -l
4343
Isn't that outbound mail*to* Microsoft-hosted domains? I wouldn't
expect that to appear in logs of incoming ma
BTW I explicitly allow mail from their IP ranges at postscreen level:
...
#outlook.com
40.92.0.0/15permit
40.107.0.0/16 permit
52.100.0.0/14 permit
104.47.0.0/17 permit
they published some more ranges but when I checked, I haven't noticed mail from
oth
There is currently a similar thread on "mailop" mailing list about
connections from MS to *submission* ports, that connect, do valid AUTH
(using proper credentials!) and then hang up.
People in that thread suspect that this behavior might be associated with
connections from Outlook mobile app bei
11 matches
Mail list logo
