[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Wed, Oct 18, 2023 at 10:17:52PM +0200, Markus Ueberall wrote:
> On 18.10.23, 22:11 Markus Ueberall wrote via Postfix-users:
> > I just tried an explicit "_25._tcp" CNAME as suggested above (using the
> > shared RRset) /alongside/ the existing "*._tcp" CNAME which I did not
> > want to remove/replace for one domain ("D1") while keeping my
> > aforementioned setup for a second domain ("D2"). Then I waited for a
> > couple of hours to be sure that all outdated cache entries are gone (TTL
> > for all entries is 3600 seconds), and sent another test e-mail each to
> > both domains (one immediately after the other). Lo and behold: The one
> > addressed to D2 got delivered, the one addressed to D1 still causes the
> > logs to be filled with the same dreaded STARTTLS,QUIT pattern at the
> > time of writing.
> >
> > This means that it's either not only the required lookup of a wildcard
> > CNAME that causes problems or the simple fact that there is a wildcard
> > CNAME although it should be ignored in this case.
>
> Sorry, scratch the second part of the last sentence after "or the simple
> fact"; "D2" also still has said wildcard CNAME.
So what's the bottom line. Are Microsoft's outbound MTAs, in fact,
having problems delivering mail to domains with additional non-matching
TLSA records? Or is the problem some other aspect of your
configuration?
Possible factors:
- Use of TLSA CNAMEs (wildcard or otherwise)?
- Size of TLSA RRsets?
- Mixture of "3 1 1" and "3 1 2" records?
- Deploying both ECDSA and RSA?
- Publishing both "2 1 X" and "3 1 X" records?
Have you opened a ticket with Microsoft? Though it would take some
effort on your part, it would be rather beneficial to the broader
ecosystem, and to your ability to later make configuration changes
with confidence, to find the root cause of the issues you're reporting.
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On 18.10.23, 22:11 Markus Ueberall wrote via Postfix-users:
I just tried an explicit "_25._tcp" CNAME as suggested above (using
the shared RRset) /alongside/ the existing "*._tcp" CNAME which I did
not want to remove/replace for one domain ("D1") while keeping my
aforementioned setup for a second domain ("D2"). Then I waited for a
couple of hours to be sure that all outdated cache entries are gone
(TTL for all entries is 3600 seconds), and sent another test e-mail
each to both domains (one immediately after the other). Lo and behold:
The one addressed to D2 got delivered, the one addressed to D1 still
causes the logs to be filled with the same dreaded STARTTLS,QUIT
pattern at the time of writing.
This means that it's either not only the required lookup of a wildcard
CNAME that causes problems or the simple fact that there is a wildcard
CNAME although it should be ignored in this case.
Sorry, scratch the second part of the last sentence after "or the simple
fact"; "D2" also still has said wildcard CNAME.
KR, Markus
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On 17.10.23, 18:42 Viktor Dukhovni wrote via Postfix-users:
On Tue, Oct 17, 2023 at 05:47:11PM +0200, Markus Ueberall via Postfix-users
wrote:
For the record: I stumbled across this a couple of days ago when I received
a message on LinkedIn telling me that a number of e-mails sent via
Microsoft's outbound systems had bounced. Given that occasional tests using
MECSA (https://mecsa.jrc.ec.europa.eu/) and DNSSEC and DANE Validation (part
of the Microsoft Remote Connectivity Analyzer,
https://testconnectivity.microsoft.com/tests/O365DaneValidation/input)
looked /good/ (all TLSA entries for ECDSA/RSA certificates used by a certain
domain and its subdomains were always listed under subname "_tcp", with a
couple of CNAME entries "*._tcp", "[*.]_tcp.subdomain", ... pointing to said
subname), it took a while to realize that the above "STARTTLS,QUIT"
behaviour is due to the fact that said outbound systems do not like to come
across non-matching TLSA entries (for other certificates used by the
webserver) anymore.
Are you *SURE* about that? That would be a substantial departure from
the DANE specifications. Extraneous *non-matching* DANE TLSA records
MUST be simply ignored. Any single *matching* TLSA records is
sufficient.
The simple solution was to introduce a new specific subname "_25._tcp"
(which takes precedence over the generic "*._tcp" CNAME) and duplicate/move
the TLSA entries directly related to the certificate used by postfix for the
(sub)domain(s) in question there. In hindsight, this means: Whenever the
MRCA test results (see above) show something marked in red, you should check
whether it's possible to modify your configuration.
If the new TLSA RRset at _25._tcp. prefix is a proper subset of the
original (wildcard or explicit CNAME) shared RRset, and delivery works
for the subset and not the whole set, then there's a genuine problem with
the sender's implementation.
Have you tried using an explicit CNAME instead of a wildcard CNAME, and
still using the shared RRset:
_25._tcp.smtp.acme.example. IN CNAME _tcp.acme.example.
_tcp.acme.example. IN TLSA 3 1 1 ...
_tcp.acme.example. IN TLSA 3 1 1 ...
...
I just tried an explicit "_25._tcp" CNAME as suggested above (using the
shared RRset) /alongside/ the existing "*._tcp" CNAME which I did not
want to remove/replace for one domain ("D1") while keeping my
aforementioned setup for a second domain ("D2"). Then I waited for a
couple of hours to be sure that all outdated cache entries are gone (TTL
for all entries is 3600 seconds), and sent another test e-mail each to
both domains (one immediately after the other). Lo and behold: The one
addressed to D2 got delivered, the one addressed to D1 still causes the
logs to be filled with the same dreaded STARTTLS,QUIT pattern at the
time of writing.
This means that it's either not only the required lookup of a wildcard
CNAME that causes problems or the simple fact that there is a wildcard
CNAME although it should be ignored in this case. Now, I could go on and
introduce a second certificate listed below "_25._tcp" (in order to have
a valid RSA, ECDSA combo) and/or remove all wildcard CNAME entries, but
I already spent a couple of hours with the above and the current setup
for D2 (which I will restore for D1) suits my/our current needs (see
below). Either way, as you mentioned above, the behaviour (1) does *not*
seem to be in line with the DANE specifications and (2) also differs
from what is shown in the Microsoft Remote Connectivity Analyzer test
results.
By the way, thanks a lot for the thorough analysis of the
projektzentrisch.de (test) domain, but although I use that one *here*,
it's not one of the two "Dn" in question (although it has the same basic
setup as described in my previous posting above and utilizes the same
DNS hosting service, the two company domains I actually used for the
comparison/tests above have *way less* DNS entries, certificates).
KR, Markus
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Tue, Oct 17, 2023 at 12:42:39PM -0400, Viktor Dukhovni via Postfix-users wrote: > > [...] it took a while to realize that the above "STARTTLS,QUIT" > > behaviour is due to the fact that said outbound systems do not like to come > > across non-matching TLSA entries (for other certificates used by the > > webserver) anymore. > > Are you *SURE* about that? That would be a substantial departure from > the DANE specifications. Extraneous *non-matching* DANE TLSA records > MUST be simply ignored. Any single *matching* TLSA records is > sufficient. It is also worth noting that "non-matching" TLSA records are fundamentally unavoidable for SMTP servers with both RSA and ECDSA certificates that publish DANE-EE(3) records. This includes "postfix.org": https://stats.dnssec-tools.org/explore/?postfix.org https://testconnectivity.microsoft.com/result/72f862c1-fdab-46ab-4ba8-f32807a7c303 Any one TLS handshake will negotiate either RSA or ECDSA signature algorithms, and will find only the corresponding TLSA records matching. The TLSA record for non-selected algorithm's key will not match. This can also apply when using "2 1 1" records for the intermediate CA, if different intermediate issuers are used for RSA vs. ECDSA, as is the case with Let's Encrypt (R3/R4 vs. E1/E2). So I am very sceptical that Microsoft have issues delivering mail based on mere presence of some non-matching TLSA records. The bounces the OP alluded to (with no specifics as to what reason was reported in the bounce beyond "a message on LinkedIn telling me that a number of e-mails sent via Microsoft's outbound systems had bounced") could even be entirely unrelated to DANE (red herring). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Tue, Oct 17, 2023 at 05:47:11PM +0200, Markus Ueberall via Postfix-users wrote: > On 17.08.23, 01:48 Viktor Dukhovni wrote via Postfix-users: > > So far, the pattern of Microsoft's outbound systems disconnecting > > immediately after a completed TLS handshake strongly correlates with a > > broken TLSA setup. > > For the record: I stumbled across this a couple of days ago when I received > a message on LinkedIn telling me that a number of e-mails sent via > Microsoft's outbound systems had bounced. Given that occasional tests using > MECSA (https://mecsa.jrc.ec.europa.eu/) and DNSSEC and DANE Validation (part > of the Microsoft Remote Connectivity Analyzer, > https://testconnectivity.microsoft.com/tests/O365DaneValidation/input) > looked /good/ (all TLSA entries for ECDSA/RSA certificates used by a certain > domain and its subdomains were always listed under subname "_tcp", with a > couple of CNAME entries "*._tcp", "[*.]_tcp.subdomain", ... pointing to said > subname), it took a while to realize that the above "STARTTLS,QUIT" > behaviour is due to the fact that said outbound systems do not like to come > across non-matching TLSA entries (for other certificates used by the > webserver) anymore. Are you *SURE* about that? That would be a substantial departure from the DANE specifications. Extraneous *non-matching* DANE TLSA records MUST be simply ignored. Any single *matching* TLSA records is sufficient. > The simple solution was to introduce a new specific subname "_25._tcp" > (which takes precedence over the generic "*._tcp" CNAME) and duplicate/move > the TLSA entries directly related to the certificate used by postfix for the > (sub)domain(s) in question there. In hindsight, this means: Whenever the > MRCA test results (see above) show something marked in red, you should check > whether it's possible to modify your configuration. If the new TLSA RRset at _25._tcp. prefix is a proper subset of the original (wildcard or explicit CNAME) shared RRset, and delivery works for the subset and not the whole set, then there's a genuine problem with the sender's implementation. Have you tried using an explicit CNAME instead of a wildcard CNAME, and still using the shared RRset: _25._tcp.smtp.acme.example. IN CNAME _tcp.acme.example. _tcp.acme.example. IN TLSA 3 1 1 ... _tcp.acme.example. IN TLSA 3 1 1 ... ... Perhaps they just have issues with wildcard-synthesised CNAMEs? $ dig +dnssec +nocmd +nocl +nottl +nocrypto -t tlsa _25._tcp.node1.projektzentrisch.de. ;; Truncated, retrying in TCP mode. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19327 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 23, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1400 ;; QUESTION SECTION: ;_25._tcp.node1.projektzentrisch.de. IN TLSA ;; ANSWER SECTION: _25._tcp.node1.projektzentrisch.de. CNAME _tcp.projektzentrisch.de. _25._tcp.node1.projektzentrisch.de. RRSIG CNAME 13 4 3600 2023102600 2023100500 25749 projektzentrisch.de. [omitted] _tcp.projektzentrisch.de. TLSA 2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B220407 1ED04F10 _tcp.projektzentrisch.de. TLSA 2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18 _tcp.projektzentrisch.de. TLSA 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DC FBCF286D _tcp.projektzentrisch.de. TLSA 2 1 2 0F644C9A1DCB8C04BE6B385A60DBE4FDF7E2B81E335C9AD8C7CD0ABE 2FF9E7E5BBFBB68B38DD0216F17808F48BDF6AF8C6347659C1F41A98 58032C31F436D12C _tcp.projektzentrisch.de. TLSA 2 1 2 3561540FBF182BCE7749ACC131B421E691F083569C053E78F2027471 4C5E801226FF6EDB60641DDF70E71BD3A90DFE25DDD6464BE78106B7 7DECE4F6A3BFF13D _tcp.projektzentrisch.de. TLSA 2 1 2 774FAD8C9A6AFC2BDB44FABA8390D213AE592FB0D56C5DFAB152284E 334D7CD6ABD05799236E7AA6266EDF81907C60404C57EE54C10A3A82 FCC2A9146629B140 _tcp.projektzentrisch.de. TLSA 3 1 1 1658A1AB90437DEA0BC2F855611DAD7A4AD11FE1BA3F2DFDF69E992B 8FF9513D _tcp.projektzentrisch.de. TLSA 3 1 1 34E64B8E329F0F5C94A1EC6B11EF65CF87902A99E4B29A4D4E117631 75083D26 _tcp.projektzentrisch.de. TLSA 3 1 1 C887C34E3FB37DBEBB62E6840E2403473D4E81B8F97DDAD3791CC12F DE0DD4E5 _tcp.projektzentrisch.de. TLSA 3 1 1 CB0109E6FD1E9AA463240E6325A96EA8CCAEB80602E65FE52D6B996C 7F1DC147 _tcp.projektzentrisch.de. TLSA 3 1 2 2D441EFBDCF23127AFE6CA71EA246C01FA9BC1DA02DF1BB487711511 305D96386B027CC353EB414757B6C5D072C7803CB9879B1C8ECCEEBA 472D43F7E4B68B64 _tcp.projektzentrisch.de. TLSA 3 1 2 3B3779319C8A8A1454A81176836487B849B9B91141B1EEE6B80AC17C E8F7679311E1F45BF1D1F71E0A5EEFA533CF8D9B35006CF6E85AF1EB 0AC2603C9B4BE3A8 _tcp.projektzentrisch.de. TLSA 3 1 2 56A671F5ED718EADF4FD6376E800E5FC6F82ECBE13AD8D6283742DF6 1F99A129125DE8BC2106182D50672CF69FEF42AA97AA8D0C21506AD4 481D7A21B450EE9F _tcp.projektzentrisch.de. TLSA 3 1 2 5A459743D85930AB16B8F6006257A0530981F97D42
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On 17.08.23, 01:48 Viktor Dukhovni wrote via Postfix-users: So far, the pattern of Microsoft's outbound systems disconnecting immediately after a completed TLS handshake strongly correlates with a broken TLSA setup. For the record: I stumbled across this a couple of days ago when I received a message on LinkedIn telling me that a number of e-mails sent via Microsoft's outbound systems had bounced. Given that occasional tests using MECSA (https://mecsa.jrc.ec.europa.eu/) and DNSSEC and DANE Validation (part of the Microsoft Remote Connectivity Analyzer, https://testconnectivity.microsoft.com/tests/O365DaneValidation/input) looked /good/ (all TLSA entries for ECDSA/RSA certificates used by a certain domain and its subdomains were always listed under subname "_tcp", with a couple of CNAME entries "*._tcp", "[*.]_tcp.subdomain", ... pointing to said subname), it took a while to realize that the above "STARTTLS,QUIT" behaviour is due to the fact that said outbound systems do not like to come across non-matching TLSA entries (for other certificates used by the webserver) anymore. The simple solution was to introduce a new specific subname "_25._tcp" (which takes precedence over the generic "*._tcp" CNAME) and duplicate/move the TLSA entries directly related to the certificate used by postfix for the (sub)domain(s) in question there. In hindsight, this means: Whenever the MRCA test results (see above) show something marked in red, you should check whether it's possible to modify your configuration. KR, Markus ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Wed, Aug 16, 2023 at 06:22:28PM -0400, pgnd via Postfix-users wrote:
> not exactly the same issue to my read, but there may be more to it?
As suspected, the OP has an incomplete DANE TLSA RRset that fails to
match the system's RSA certificate (the additional ECDSA certifcate does
match, but Microsoft's outbound servers negotiate RSA).
See:
https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
https://mail.sys4.de/pipermail/dane-users/2017-August/000416.html
So far, the pattern of Microsoft's outbound systems disconnecting
immediately after a completed TLS handshake strongly correlates with a
broken TLSA setup.
In this case, one that would not be found by the DANE survey, because
the code currently prefers ECDSA, but I should perhaps implement a
random client-side preference to have a better chance of detecting this
issue (or just prefer RSA over ECDSA on odd day numbers since the
epoch). That would still fail to find problem systems that ignore the
client preference order and only expose the second algorithm's
certificate when it is the only one supported by the client.
Problem found via:
danesmtp ()
{
local host=$1;
shift;
local opts=(-starttls smtp -connect "$host:25" -verify 9
-verify_return_error -dane_ee_no_namechecks -dane_tlsa_domain "$host");
set -- $(dig +short +nosplit -t tlsa "_25._tcp.$host" | egrep -i '^[23]
[01] [012] [0-9a-f]+$');
while [ $# -ge 4 ]; do
opts=("${opts[@]}" "-dane_tlsa_rrdata" "$1 $2 $3 $4");
shift 4;
done;
( sleep 1;
printf "QUIT\r\n" ) | openssl s_client -tls1_2 -cipher 'aRSA:aECDSA'
"${opts[@]}"
}
Possible choices for "-cipher" are:
- aRSA:aECDSA
- aECDSA:aRSA
- aECDSA
- aRSA
If any fail with a certificate verification problem due to a mismatched
TLSA record (rather than failure to find a common ciphersuite), you have
a TLSA misconfiguration.
Always simplest to stick to just one widely supported algorithm, for
now, in most cases a vanilla RSA cert with a 2048-bit key.
Though perhaps all SMTP clients capable of doing DANE are sufficiently
bleeding edge to also be expected to support ECDSA (P256).
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
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 being proxied by MS servers. Probably something went wrong there. No definite conclusion yet. thx for the ref -- found the thread on mailop. not exactly the same issue to my read, but there may be more to it? in any case, it'd be at least consistent some legit sends from *outlook.com making it thru, and such other mobile/proxied attempts not. wait -n- see ... ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
Dnia 15.08.2023 o godz. 16:14:58 pgnd via Postfix-users pisze: > they come in frequent waves of ~5-10 from countless different outlook.com > hosts -- but, so far, these waves (and totals) are ONLY from outlook.com > -- getting by postscreen cache after expire with "PASS NEW". > > i never receive content with these; i just see the connect->disconnect > sequence. protections appear to be doing what they should. > > 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 > > any wisdom as to what this M$ noise is ? and what (else) to do about it? > if anything ... 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 being proxied by MS servers. Probably something went wrong there. No definite conclusion yet. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Wed, Aug 16, 2023 at 02:07:39PM +, Serg wrote: > Thanks for pointing this out, I forgot to update it when migrating from RSA > to ECC certificate. It seems you don't have monitoring in place that checks the correctness of your TLSA records vis-à-vis your certificate chain. Monitoring is an essential part of deploying inbound DANE TLSA. My standard advice is to deploy the monitoring first, and only then deploy DANE. You should be the first to know if and when something goes wrong. Also consider: https://github.com/tlsaware/danebot [ Contributions of code to implement "hooks" welcome, as well as code to support changing the list of requested DNS names without having to change the key. The github project could also be a place to host similar functionality for other ACME clients. ] > > Far less hassle (a few extra *lines* in the log per day) than not being > > able to receive mail. And you contribute to the survey stats. > > Oh, haven't thought it has such functionality (shodan/censys/etc never > reached me due to any security issues found). The primary purpose of the survey is to keep the DANE ecosystem in a clean-enough state to not hamper further adoption. If too many domains had broken TLSA records, DANE would wither away without ever reaching critical mass. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On 8/16/23 13:55, Viktor Dukhovni via Postfix-users wrote: There's good reason for that, your MX host has DANE TLSA records that don't match its certificate chain: Thanks for pointing this out, I forgot to update it when migrating from RSA to ECC certificate. On 8/16/23 13:55, Viktor Dukhovni via Postfix-users wrote: Your server refuses SMTP connections from the DANE survey, flopster.at.encryp.ch[65.21.140.233]: GREETING 554 5.7.1 : Unverified Client host rejected: opt-out from the research flopster.at.encryp.ch[2a01:4f9:3b:2a5f:86e2:89a:e1f7:b837]: GREETING 554 5.7.1 : Unverified Client host rejected: opt-out from the research so, unfortunately, you've also not been previously notified of this problem. I would like to encourage postmasters to not block SMTP connections from the DANE survey: https://stats.dnssec-tools.org/about.html There is typically just one connection a day per MX IP address, perhaps a couple of extra connections if a problem is found. Far less hassle (a few extra *lines* in the log per day) than not being able to receive mail. And you contribute to the survey stats. Oh, haven't thought it has such functionality (shodan/censys/etc never reached me due to any security issues found). ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Wed, Aug 16, 2023 at 10:56:07AM +, Serg via Postfix-users wrote:
> I have checked email server of mine and can confirm I am seeing that too
> (logs are since Aug 13 03:50:38 EEST):
>
> > admin@flopster ~ $ sudo grep -e .outbound.protection.outlook.com
> > /var/log/mail.log | grep 'ehlo=1 starttls=1 quit=1 commands=3' | tail
> > Aug 16 13:47:34 flopster postfix/smtpd[23237]: disconnect from
> > mail-mw2nam12on20617.outbound.protection.outlook.com[2a01:111:f400:fe5a::617]
> > ehlo=1 starttls=1 quit=1 commands=3
> > [...]
There's good reason for that, your MX host has DANE TLSA records that
don't match its certificate chain:
$ danesmtp ()
{
local host=$1;
shift;
local opts=(-starttls smtp -connect "$host:25" -verify 9
-verify_return_error -brief -dane_ee_no_namechecks -dane_tlsa_domain "$host");
set -- $(dig +short +nosplit -t tlsa "_25._tcp.$host" | egrep -i '^[23]
[01] [012] [0-9a-f]+$');
while [ $# -ge 4 ]; do
opts=("${opts[@]}" "-dane_tlsa_rrdata" "$1 $2 $3 $4");
shift 4;
done;
( sleep 1;
printf "QUIT\r\n" ) | openssl s_client "${opts[@]}"
}
$ danesmtp flopster.at.encryp.ch
verify depth is 9
depth=0 CN = flopster.at.encryp.ch
verify error:num=65:No matching DANE TLSA records
34371133440:error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify
failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1921:
Microsoft supports DANE outbound and will not deliver mail to sites with
misconfigured TLSA records. This can only be discovered as part of
completing the TLS handshake.
Your server refuses SMTP connections from the DANE survey,
flopster.at.encryp.ch[65.21.140.233]: GREETING 554 5.7.1
: Unverified Client host rejected: opt-out from the
research
flopster.at.encryp.ch[2a01:4f9:3b:2a5f:86e2:89a:e1f7:b837]: GREETING 554
5.7.1 : Unverified Client host rejected: opt-out from
the research
so, unfortunately, you've also not been previously notified of this
problem.
I would like to encourage postmasters to not block SMTP connections from
the DANE survey: https://stats.dnssec-tools.org/about.html
There is typically just one connection a day per MX IP
address, perhaps a couple of extra connections if a problem is found.
Far less hassle (a few extra *lines* in the log per day) than not being
able to receive mail. And you contribute to the survey stats.
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Wed, Aug 16, 2023 at 09:12:44AM -0400, pgnd via Postfix-users wrote: > 4 0.321516 192.0.2.25 → 52.101.62.16 SMTP 121 S: 220 > mx1.example.net ESMTP . Your server's hostname and served domains continue to be hidden. Are you perhaps willing and able to post those details? Without that information, no further differential diagnostics are possible. > 4 0.318693 192.0.2.25 → 209.85.128.182 SMTP 133 S: 220 > mx1.example.net ESMTP . I am assuming your server's name isn't actually mx1.example.net, certainly not what Microsoft is connecting to, since that name has no IP address in the public DNS (example.net is an IANA reserved name for use in documentation). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
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 other than these ranges i suppose that can't hurt here. i added the ranges, and, as expected, see ALLOWLISTED @ postscreen; tho, the connection still terminates as above. taking a stab at looking at TLS, for one of these short/failed from-outlook.com attempts, tshark -nr /tmp/tls.pcap 1 0.00 52.101.62.16 → 192.0.2.25 TCP 66 60645 → 25 [SYN] Seq=0 Win=64240 Len=0 MSS=1378 WS=256 SACK_PERM 2 0.000211 192.0.2.25 → 52.101.62.16 TCP 66 25 → 60645 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM WS=1 3 0.044868 52.101.62.16 → 192.0.2.25 TCP 54 60645 → 25 [ACK] Seq=1 Ack=1 Win=525568 Len=0 4 0.321516 192.0.2.25 → 52.101.62.16 SMTP 121 S: 220 mx1.example.net ESMTP . 5 0.365891 52.101.62.16 → 192.0.2.25 SMTP 105 C: EHLO DM5PR00CU002.outbound.protection.outlook.com 6 0.365969 192.0.2.25 → 52.101.62.16 TCP 54 25 → 60645 [ACK] Seq=68 Ack=52 Win=64189 Len=0 7 0.366134 192.0.2.25 → 52.101.62.16 SMTP 185 S: 250-mx1.example.net | PIPELINING | SIZE 104857600 | STARTTLS | ENHANCEDSTATUSCODES | 8BITMIME | SMTPUTF8 8 0.410624 52.101.62.16 → 192.0.2.25 SMTP 64 C: STARTTLS 9 0.410814 192.0.2.25 → 52.101.62.16 SMTP 84 S: 220 2.0.0 Ready to start TLS 10 0.455866 52.101.62.16 → 192.0.2.25 TLSv1.2 224 Client Hello 11 0.466708 192.0.2.25 → 52.101.62.16 TLSv1.2 1432 Server Hello 12 0.466719 192.0.2.25 → 52.101.62.16 TCP 1432 25 → 60645 [PSH, ACK] Seq=1607 Ack=232 Win=64009 Len=1378 [TCP segment of a reassembled PDU] 13 0.466947 192.0.2.25 → 52.101.62.16 TLSv1.2 902 Certificate, Server Key Exchange, Server Hello Done 14 0.511121 52.101.62.16 → 192.0.2.25 TCP 54 60645 → 25 [ACK] Seq=232 Ack=2985 Win=525568 Len=0 15 0.518474 52.101.62.16 → 192.0.2.25 TLSv1.2 212 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 16 0.520753 192.0.2.25 → 52.101.62.16 TLSv1.2 296 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message 17 0.567586 52.101.62.16 → 192.0.2.25 TLSv1.2 89 Application Data 18 0.568017 192.0.2.25 → 52.101.62.16 TLSv1.2 98 Application Data 19 0.568181 192.0.2.25 → 52.101.62.16 TLSv1.2 85 Encrypted Alert 20 0.612599 52.101.62.16 → 192.0.2.25 TCP 54 60645 → 25 [ACK] Seq=425 Ack=4151 Win=524288 Len=0 21 0.613008 52.101.62.16 → 192.0.2.25 TCP 54 60645 → 25 [RST, ACK] Seq=425 Ack=4151 Win=0 Len=0 & tshark -nr /tmp/tls.pcap -V ssl ... Transmission Control Protocol, Src Port: 25, Dst Port: 60645, Seq: 2985, Ack: 232, Len: 848 Source Port: 25 Destination Port: 60645 [Stream index: 0] ?? [Conversation completeness: Incomplete, DATA (15)] ... iiuc, 15 == 1/SYN +2/SYN-ACK + 4/ACK +8/DATA and indicates the handshake lacks a FIN or RST closing sequence for an OK send, from google, tshark -nr /tmp/tls.pcap 1 0.00 209.85.128.182 → 192.0.2.25 TCP 74 47456 → 25 [SYN] Seq=0 Win=65535 Len=0 MSS=1412 SACK_PERM TSval=1170316599 TSecr=0 WS=256 2 0.000181 192.0.2.25 → 209.85.128.182 TCP 74 25 → 47456 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=3383420399 TSecr=1170316599 WS=1 3 0.023599 209.85.128.182 → 192.0.2.25 TCP 66 47456 → 25 [ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=1170316622 TSecr=3383420399 4 0.318693 192.0.2.25 → 209.85.128.182 SMTP 133 S: 220 mx1.example.net ESMTP . 5 0.342110 209.85.128.182 → 192.0.2.25 TCP 66 47456 → 25 [ACK] Seq=1 Ack=68 Win=65536 Len=0 TSval=1170316941 TSecr=3383420717 6 0.343199 209.85.128.182 → 192.0.2.25 SMTP 97 C: EHLO mail-yw1-f182.google.com 7 0.343282 192.0.2.25 → 209.85.128.182 TCP 66 25 → 47456 [ACK] Seq=68 Ack=32 Win=65129 Len=0 TSval=3383420742 TSecr=1170316942 8 0.343408 192.0.2.25 → 209.85.128.182 SMTP 197 S: 250-mx1.example.net | PIPELINING | SIZE 104857600 | STARTTLS | ENHANCEDSTATUSCODES | 8BITMIME | SMTPUTF8 9 0.367327 209.85.128.182 → 192.0.2.25 SMTP 76 C: STARTTLS 10 0.367387 192.0.2.25 → 209.85.128.182 SMTP 96 S: 220 2.0.0 Ready to start TLS 11 0.391656 209.85.128.182 → 192.0.2.25 TLSv1 583 Client Hello 12 0.393450 192.0.2.25 → 209.85.128.182 TLSv1.3 1466 Server Hello,
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
I have checked email server of mine and can confirm I am seeing that too (logs are since Aug 13 03:50:38 EEST): admin@flopster ~ $ sudo grep -e .outbound.protection.outlook.com /var/log/mail.log | grep 'ehlo=1 starttls=1 quit=1 commands=3' | tail Aug 16 13:47:34 flopster postfix/smtpd[23237]: disconnect from mail-mw2nam12on20617.outbound.protection.outlook.com[2a01:111:f400:fe5a::617] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:47:35 flopster postfix/smtpd[17815]: disconnect from mail-mw2nam12on2066.outbound.protection.outlook.com[40.107.244.66] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:48:30 flopster postfix/smtpd[23237]: disconnect from mail-db3eur04hn2210.outbound.protection.outlook.com[52.100.17.210] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:48:31 flopster postfix/smtpd[21126]: disconnect from mail-db3eur04hn031a.outbound.protection.outlook.com[2a01:111:f400:fe0c::31a] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:49:55 flopster postfix/smtpd[21126]: disconnect from mail-dm6nam12hn2213.outbound.protection.outlook.com[52.100.166.213] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:49:57 flopster postfix/smtpd[23237]: disconnect from mail-dm6nam12hn2031b.outbound.protection.outlook.com[2a01:111:f400:fe59::31b] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:50:33 flopster postfix/smtpd[23237]: disconnect from mail-mw2nam10hn2238.outbound.protection.outlook.com[52.100.157.238] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:50:35 flopster postfix/smtpd[21126]: disconnect from mail-mw2nam10hn20321.outbound.protection.outlook.com[2a01:111:f400:7e89::321] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:52:03 flopster postfix/smtpd[23237]: disconnect from mail-bn8nam11hn2200.outbound.protection.outlook.com[52.100.171.200] ehlo=1 starttls=1 quit=1 commands=3 Aug 16 13:52:03 flopster postfix/smtpd[21126]: disconnect from mail-bn8nam11hn20300.outbound.protection.outlook.com[2a01:111:f400:7eae::300] ehlo=1 starttls=1 quit=1 commands=3 admin@flopster ~ $ sudo grep -e .outbound.protection.outlook.com /var/log/mail.log | grep 'ehlo=1 starttls=1 quit=1 commands=3' | wc -l 10443 On 8/16/23 10:46, Emmanuel Fusté via Postfix-users wrote: Le 15/08/2023 à 23:12, Viktor Dukhovni via Postfix-users a écrit : On Tue, Aug 15, 2023 at 04:14:58PM -0400, pgnd via Postfix-users wrote: 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[27910]: PASS NEW [52.101.56.17]:32607 2023-08-14T13:12:00.058029-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: connect from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] 2023-08-14T13:12:00.118201-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: Anonymous TLS connection established from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) 2023-08-14T13:12:00.131049-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: disconnect from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] ehlo=1 starttls=1 quit=1 commands=3 Perhaps they don't like your certificate and disconnect once the handshake completes. I second that. But as outbound policy could be personalized by client/tenant hosted on O365 you're lost until someone start winning at you by another channel or retract the offending specific configuration, all conditioned by logs inspections and/or end user complains on their side. Already run into here. Emmanuel. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
Le 15/08/2023 à 23:12, Viktor Dukhovni via Postfix-users a écrit : On Tue, Aug 15, 2023 at 04:14:58PM -0400, pgnd via Postfix-users wrote: 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[27910]: PASS NEW [52.101.56.17]:32607 2023-08-14T13:12:00.058029-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: connect from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] 2023-08-14T13:12:00.118201-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: Anonymous TLS connection established from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) 2023-08-14T13:12:00.131049-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: disconnect from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] ehlo=1 starttls=1 quit=1 commands=3 Perhaps they don't like your certificate and disconnect once the handshake completes. I second that. But as outbound policy could be personalized by client/tenant hosted on O365 you're lost until someone start winning at you by another channel or retract the offending specific configuration, all conditioned by logs inspections and/or end user complains on their side. Already run into here. Emmanuel. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Tue, Aug 15, 2023 at 04:14:58PM -0400, pgnd via Postfix-users wrote: 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[27910]: PASS NEW [52.101.56.17]:32607 2023-08-14T13:12:00.058029-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: connect from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] 2023-08-14T13:12:00.118201-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: Anonymous TLS connection established from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) 2023-08-14T13:12:00.131049-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: disconnect from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] ehlo=1 starttls=1 quit=1 commands=3 On 15.08.23 17:12, Viktor Dukhovni via Postfix-users wrote: Perhaps they don't like your certificate and disconnect once the handshake completes. What are some of the domains this server is an MX host for? I have certificate signed by my personal CA and receive mail from microsoft services w/o problems. BTW I explicitly allow mail from their IP ranges at postscreen level: #google 209.85.128.0/17 permit 74.125.0.0/16 permit #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 other than these ranges 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 mail. correct -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Honk if you love peace and quiet. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Tue, Aug 15, 2023 at 05:12:53PM -0400, Viktor Dukhovni via Postfix-users wrote: > > 2023-08-14T13:12:00.131049-04:00 svr01 > > postfix/postscreen-internal/smtpd[27907]: disconnect from > > mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] > > ehlo=1 starttls=1 quit=1 commands=3 > > Perhaps they don't like your certificate and disconnect once the > handshake completes. What are some of the domains this server is an > MX host for? This is the key question that would have been useful to respond to. > > 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 mail. This was just an observation that quoted count has no bearing on inbound mail. On Tue, Aug 15, 2023 at 06:02:20PM -0400, pgnd wrote: > >> 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 mail. > > i grabbed the 250 for my grep from proxy-accept, just for counting convenience > e.g., here's an ok inbound that was accepted/delivered; There was no need for these. What are some domains that the server MX-hosts? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
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 mail. i grabbed the 250 for my grep from proxy-accept, just for counting convenience e.g., here's an ok inbound that was accepted/delivered; 2023-07-17T10:19:12.601557-04:00 svr01 postfix/postscreen[44132]: CONNECT from [40.107.244.113]:33056 to [xx.xx.xx.xx]:25 2023-07-17T10:19:18.800849-04:00 svr01 postfix/postscreen[44132]: PASS NEW [40.107.244.113]:33056 2023-07-17T10:19:18.926665-04:00 svr01 postfix/ps-int/smtpd[44136]: connect from mail-mw2nam12on2113.outbound.protection.outlook.com[40.107.244.113] 2023-07-17T10:19:19.247918-04:00 svr01 postfix/ps-int/smtpd[44136]: Untrusted TLS connection established from mail-mw2nam12on2113.outbound.protection.outlook.com[40.107.244.113]: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits) 2023-07-17T10:19:21.649503-04:00 svr01 auth-milter[34494]: 4325636CF1D: ERROR: Error parsing existing Authentication-Results header: dkim=none (message not signed)#015 header.d=none;dmarc=none action=none header.from=example2.com; 2023-07-17T10:19:21.368763-04:00 svr01 postfix/ps-int/smtpd[44136]: NOQUEUE: client=mail-mw2nam12on2113.outbound.protection.outlook.com[40.107.244.113] 2023-07-17T10:19:21.992068-04:00 svr01 milter-regex[1108]: localhost.mx1.example1.net [127.0.0.1]: ACCEPT, HELO: auth-milter.mx1.example2.net, FROM: , RCPT: , From:someone , To: me , Subject: 2023-07-17T10:19:21.927171-04:00 svr01 postfix/preQ/smtpd[44140]: connect from localhost.mx1.example1.net[127.0.0.1] 2023-07-17T10:19:21.938905-04:00 svr01 postfix/preQ/smtpd[44140]: 4RF2p96g9nz5K: client=localhost.mx1.example1.net[127.0.0.1], orig_client=mail-mw2nam12on2113.outbound.protection.outlook.com[40.107.244.113] 2023-07-17T10:19:21.941334-04:00 svr01 postfix/cleanup[44143]: 4RF2p96g9nz5K: message-id= 2023-07-17T10:19:22.020339-04:00 svr01 clamav-milter[5784]: Clean message from to 2023-07-17T10:19:28.048393-04:00 svr01 postfix/qmgr[1360]: 4RF2p96g9nz5K: from=, size=13112, nrcpt=1 (queue active) 2023-07-17T10:19:28.049981-04:00 svr01 postfix/ps-int/smtpd[44136]: proxy-accept: END-OF-MESSAGE: 250 2.0.0 Queued as 4325636CF1D; from= to= proto=ESMTP helo= 2023-07-17T10:19:28.052131-04:00 svr01 postfix/preQ/smtpd[44140]: disconnect from localhost.mx1.example1.net[127.0.0.1] ehlo=1 xforward=3 mail=1 rcpt=1 data=1 quit=1 commands=8 2023-07-17T10:19:28.171477-04:00 svr01 postfix/ps-int/smtpd[44136]: disconnect from mail-mw2nam12on2113.outbound.protection.outlook.com[40.107.244.113] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 2023-07-17T10:19:28.268685-04:00 svr01 postfix/relay-mx2/smtp[44150]: Verified TLS connection established to internal.mx2.example2.net[172.28.25.1]:25: TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X448 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature ECDSA (secp384r1) client-digest SHA384 2023-07-17T10:19:28.955906-04:00 svr01 postfix/relay-mx2/smtp[44150]: 4RF2p96g9nz5K: to=, relay=internal.mx2.example2.net[172.28.25.1]:25, delay=7, delays=6.1/0.01/0.49/0.4, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4RF2pJ53hDzWf3r) 2023-07-17T10:19:28.956613-04:00 svr01 postfix/qmgr[1360]: 4RF2p96g9nz5K: removed i'll look some more at TLS handshake, but can't yet grok why it'd work in some cases, and not others -- from *.outlook.com as mentioned above, hardly a stress blip to worry about ... ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
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 inquiries Maybe they don't like something about the cipher used, but that seems unlikely since the session seems to be established normally. Maybe they have a message bigger than your announced SIZE=, but that shouldn't result in repeated connections. Maybe they just have something stuck in their queue. At any rate, nothing you can do about any of this. fwiw, here 250-SIZE 104857600 i'd expect (well, hope) that all the outlook.com servers were config'd similarly. if they are, then i wouldn't expect to see _any_ *.outlook.com traffic; i do. tho, atm, the good/bad ratio is dropping like a stone. I guess twiddle the TLS knobs (or use the defaults) to maybe get them to use a different cipher, but that's just a shot in the dark and frankly I'd be surprised if it helped. i've already dropped back to defaults. no change in behavior. i was wondering if there was something to _add_; sounds like a likely no. What should you do? Just ignore it. Unless it gets to the DDOS point, even thousands of short-lived ghost connections won't stress postfix or interfere with other mail. point taken. i certainly haven't noticed any related load blips as a result. The biggest annoyance is junking up the logs. +1 You could try to catch a tcp dump of one of the offending connections, but I expect that will look perfectly normal from your end. as far as i recognize 'normal', vs typical, that's been the case; i'll poke again, but TBH, not really worth the diagnostic bother beyond the annoyance. as long as something isn't broken on my end; so far, i haven't see anything that looks like anything more than noise. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On Tue, Aug 15, 2023 at 04:14:58PM -0400, pgnd via Postfix-users wrote: > 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[27910]: PASS NEW > [52.101.56.17]:32607 > 2023-08-14T13:12:00.058029-04:00 svr01 > postfix/postscreen-internal/smtpd[27907]: connect from > mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] > 2023-08-14T13:12:00.118201-04:00 svr01 > postfix/postscreen-internal/smtpd[27907]: Anonymous TLS connection > established from > mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17]: > TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) > 2023-08-14T13:12:00.131049-04:00 svr01 > postfix/postscreen-internal/smtpd[27907]: disconnect from > mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] ehlo=1 > starttls=1 quit=1 commands=3 Perhaps they don't like your certificate and disconnect once the handshake completes. What are some of the domains this server is an MX host for? > 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 mail. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?
On 8/15/2023 3:14 PM, pgnd via Postfix-users wrote: 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[27910]: PASS NEW [52.101.56.17]:32607 2023-08-14T13:12:00.058029-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: connect from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] 2023-08-14T13:12:00.118201-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: Anonymous TLS connection established from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) 2023-08-14T13:12:00.131049-04:00 svr01 postfix/postscreen-internal/smtpd[27907]: disconnect from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] ehlo=1 starttls=1 quit=1 commands=3 they come in frequent waves of ~5-10 from countless different outlook.com hosts -- but, so far, these waves (and totals) are ONLY from outlook.com -- getting by postscreen cache after expire with "PASS NEW". i never receive content with these; i just see the connect->disconnect sequence. protections appear to be doing what they should. 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 any wisdom as to what this M$ noise is ? and what (else) to do about it? if anything ... So they connect, say EHLO, start a TLS session, and disconnect. There is no protection you can add to prevent this, other than firewalling them completely. Why do they do this? Only they know. Maybe they don't like something about the cipher used, but that seems unlikely since the session seems to be established normally. Maybe they have a message bigger than your announced SIZE=, but that shouldn't result in repeated connections. Maybe they just have something stuck in their queue. At any rate, nothing you can do about any of this. I guess twiddle the TLS knobs (or use the defaults) to maybe get them to use a different cipher, but that's just a shot in the dark and frankly I'd be surprised if it helped. You could try to catch a tcp dump of one of the offending connections, but I expect that will look perfectly normal from your end. What should you do? Just ignore it. Unless it gets to the DDOS point, even thousands of short-lived ghost connections won't stress postfix or interfere with other mail. The biggest annoyance is junking up the logs. -- Noel Jones ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
