Re: [mailop] Microsoft/Outlook contact for *.outbound.protection.outlook.com
> Microsoft is trying (over and > over) to send me emails, and they get past connect/disconnect. This has > been going on for a few days now, at a rate of once every 5 seconds. I also experience this. In the past, I've filed a support request with Microsoft asking for an explanation, but haven't received a satisfactory answer. An analysis of what I see shows: * no emails are sent, just a connect/STARTTLS/disconnect * the connecting IPs change Combined with when this started happening for me: * after I started blocking (at the SMTP level) selective spam emails originating from Microsoft's infrastructure Leads me to believe that these are health probes to try and check deliverability. I'm happy to be corrected/enlightened by more information. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] "The email didn't arrive" to Office 365
Statistics and debugging options are more limited on the sender to Microsoft side, but if you have an amenable recipient or an amenable admin on the recipient's side, requesting them to initiate a message trace should yield specifics on message deliverability. https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/trace-an-email-message -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Debt Collection Client Email Servers
On Mar 26, 2024, at 09:14, Chris Adams via mailop wrote: I recently started getting debt collection emails [...] And there's no "unsubscribe" or "this is not me"... Good news is there's a draft RFC presented at IETF 119 to tackle this: https://datatracker.ietf.org/doc/draft-dweekly-wrong-recipient/ -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.
Would you consider your own /64 or /48 from RIPE? It's one way of being in control of your own reputation. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?
From a spam point of view, signing up for a domain is a barrier of entry which some may consider too much trouble. This may play into why there's a larger distribution of unwanted mail on the freely-provided `*.onmicrosoft.com` subdomains. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail SMTP timeouts
Are you running exim? I have the following in my config, which seems to help the issue: # disable TCP fast open for gsmtp servers, due to a kernel bug; the bug was supposedly # fixed in 5.18, but it seems there's still some quirkiness with gmail without this # setting # # https://www.chromosphere.co.uk/2022/06/01/googles-tcp-fast-open-breaks-exim-delivery/ # https://forum.hestiacp.com/t/gmail-smtp-timeout-after-sending-data-block-connection-timed-out/4745/75 # https://github.com/myvesta/vesta/commit/c7aa6ec7494bc3b7ac4885182383c1bf88692c1b hosts_try_fastopen = !*.l.google.com : !*.googlemail.com : * Good luck, -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Intuit directly spaming
On 2023-03-04 22:58:23 +, MRob via mailop wrote: Thanks you Atro, is there popular tool for to do that in real time? There's also https://bgp.tools/, made by a friend and former colleague. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spam received from ips with forged reverse names
On Jan 5, 2023, at 14:54, Serizy via mailop wrote: but what worries me is that, the PTR resolves to the fake hostname, but the host name doesn’t resolve to the ip, logically…and the messages go to the user mailbox in Outlook.com This should not be an issue if the MTA performs both forward (A//CNAME) and reverse (PTR) DNS validation. Is there any way to report this? Others may correct me, but I believe the channels for reporting abusive PTR records lie with the body who owns those IPs. A WHOIS on the offending IPs should provide an abuse contact. Shouldn’t be even legal I think. Legal or not, that may not prevent people from doing so, as evidenced here, nor may incentivize people to rectify these abuses. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How do I break Gmail forwarding?
Block it at the receiving end. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Apple contact for strange email
Hello, I've been seeing a few mail connection attempts from Apple's IP space, which I've been rejecting due to mismatched A / and PTR records (see sample log at the end, times UTC). Is there anyone at Apple who can contact me off list? Thanks, -- Alex Oct 10 11:39:35 H=[17.240.49.64]:18357 rejected connection in "connect" ACL: host lookup failed (17.240.49.64 does not match any IP address for mr52p01nt-msbadger008105.ise.apple.com) Oct 11 11:33:50 H=[17.240.49.39]:35629 rejected connection in "connect" ACL: host lookup failed (17.240.49.39 does not match any IP address for mr45p01nt-msbadger005101.ise.apple.com) Oct 12 11:42:46 H=[17.240.49.58]:55433 rejected connection in "connect" ACL: host lookup failed (17.240.49.58 does not match any IP address for mr52p01nt-msbadger007106.ise.apple.com) Oct 13 11:27:15 H=[17.240.6.32]:25397 rejected connection in "connect" ACL: host lookup failed (17.240.6.32 does not match any IP address for st57p01nt-msbadger004101.ise.apple.com) Oct 15 12:35:44 H=[17.240.49.48]:37100 rejected connection in "connect" ACL: host lookup failed (17.240.49.48 does not match any IP address for mr52p01nt-msbadger006103.ise.apple.com) Oct 17 11:36:12 H=[17.240.49.33]:12835 rejected connection in "connect" ACL: host lookup failed (17.240.49.33 does not match any IP address for mr45p01nt-msbadger004102.ise.apple.com) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] EC certs in MTA - MTA TLS
On 2022-08-22 16:07:33 +0200, Slavko via mailop wrote: Please, can you elaborate more from where the cipher suites mismatch was coming? I mean if it was (your) server or the remote side, which provided/requested them. My mail server as the server, and my bank's mail server as the client, for example. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] EC certs in MTA - MTA TLS
On 2022-08-21 19:46:31 +, Slavko via mailop wrote: Is that typo? AFAIK both these cipher suites are usable only with RSA certificate, they difers only by ephemeral key exchange algo... Sorry, you're right that it's a typo. I just re-tested and want to clarify that: ECDHE-RSA-AES128-GCM-SHA256 is exclusive to RSA certificates, and ECDHE-ECDSA-AES128-GCM-SHA256 is exclusive to EC certificates, which is less widely supported by other MTAs. I've hobbled up a script to enumerate ciphersuites at https://gist.github.com/ahrex/8d2c15086a116bb9388424c40687f20f, which you can use to scan your local MTA to see what it supports as a server. You may also try this on remote MTAs, though they may not be as friendly to scans. Of course YMMV, since there's no guarantee that ciphersuites presented by remote MTAs as a server are the same as what's supported when they're a client connecting to you, so .pcaps are the best way to tell. Thanks for spotting my typo, -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] EC certs in MTA - MTA TLS
On 2022-08-21 12:35:18 +0200, Slavko via mailop wrote: if there are known some issues with ECcerts. Yes, there are. I ran the exact setup you described, and I had to debug a whole slew of cipher suite mismatches, bringing out tcpdump and Wireshark. The gist of my debug came down to: the nature of your certificate partially determines what cipher suites you may use, e.g. DHE-RSA-AES256-SHA256 and ECDHE-RSA-AES256-SHA256 are mutually exclusive, with the former only being available to RSA certs, and the latter only being available to EC certs. Guess which cipher suites are advertised more often during the TLS handshake. For me, the issue took a little time to discover, since mail can fall back to unsecured transmission if TLS negotiation fails, which is how I originally noticed there was an issue. My suggestion is to stick to an RSA cert for now, and wait for larger mail server adoption of TLS 1.3. There's a smaller cipher suite list in TLS 1.3, which would allow for more overlap opportunity between what you offer, and what the other side accepts. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.
Shameless plug: this discussion has gotten me to open-source my Office 365 OAuth script, which should be plug-and-play compatible with mail systems that can run python3 scripts and receive XOAUTH2 JWTs via stdin. If you'd like to give it a try, visit https://github.com/ahrex/oauth-helper-office-365 There's an example mutt integration, which I'm currently using to compose this very email. Have a good one, -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Russian crypto phish campaign via sendgrid to stolen Robinhood account
On Apr 24, 2022, at 23:09, John R Levine via mailop wrote: Anyone else seeing this? I’ve received a similar spam email supposedly from Metamask almost a month ago, from an O365 tenant to my O365 tenant: https://pastebin.com/Tb3S8BuD There are slight differences in the email I received: * the headers imply Mailgun instead of SendGrid * the sending IP was O365, unrelated to Mailgun itself -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is there any cloudflare staff here?
Reaching out off-list. -- Alexander Huynh R, Cloudflare ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Odd delay at Gmail ?
On 2022-04-20 12:51:47 +0200, Cyril - ImprovMX wrote: > What happened here ? Anecdotally, I recently switched MX servers and found that my emails from Google were also delayed for about 8 hours. The next day when I received my MTA-STS reports, I found 53 failures as reported by Google, since my then MTA-STS policy did not include the new MX server. While I can't say your issue is due to MTA-STS cache invalidation, I would suggest checking the various nuts and bolts both internally, and using external validators. Hope this helps, -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Best mailbox provider for personal domain?
> On Apr 10, 2022, at 10:40, Byron Lunz via mailop wrote: > > I don't recall seeing any discussion in this thread about how to migrate old > email messages from a Google Workspace account to a different host. Anyone > have advice or suggestions on how to do that? You could use https://takeout.google.com/ to download an mbox format. Querying "gmail api export eml site:github.com" into Google yields alternative methods for downloading a whole inbox using the Gmail API, but answers there are a bit old and might need some manual work. -- Alex ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Exchange 365 outbound connector being used as a relay
On 2022-01-29 09:15:02 +, Matthew Richardson via mailop wrote: > As a thought (probably wrong) could this be caused by your O365 users > forwarding INCOMING email to them FROM outlook.com and/or mail.alokind.com > to external addresses? Since all mail flows through Exchange 365, O365 would have to allow my users to preserve the FROM address, which seems like a security flaw. The only reasonable time I've seen this preservation is for forwarded calendar invites, which in my exim config have their own special rewrite rules, and did not trigger. Side note: forwarded calendar invites break DKIM due to this preservation. > > * Are there any safeguards in place from preventing one tenant from using > > another > >tenant's connectors? > > It is not certain that this is what is occurring. For example, your setup > would not preclude other tenants pointing their outgoing email to your Exim > (not that this would be sensible for them). Precisely! I'm looking for restrictions on O365's end to prevent another tenant from using my connector. I have yet to find any, but maybe I'm not looking hard enough. > You may wish to have some authentication between O365 and Exim. The MS > document linked discusses how to do this with certificates. The certificate setup listed at that page did not provide settings for outbound connector client certificates. From what I've found and done, I've set up a server-side certificate, which is used for legitimate connections (times UTC, fields obfuscated): Jan 29 14:04:54 webmail exim[2482103]: 1nDoLW-00APhv-Bk <= a...@e.sc H=mail-dm6nam12lp20206.outbound.protection.outlook.com (NAM12-DM6-obe.outbound.protection.outlook.com) [2a01:111:f400:fe59::206]:17704 P=esmtps L. X=TLS1.2:ECDHE_SECP384R1__ECDSA_SHA256__AES_256_GCM:256 CV=no SNI=ipv6.e.sc K S=162589 M8S=0 RT=0.202s id=79e8610b9a6e43c29cf1833a821ed...@mn2pr08mb6272.namprd08.prod.outlook.com T="FW: BBB" from for c...@ddd.ee Comparing that to the fields in the original blocked connection: Jan 28 10:38:40 webmail exim[2145158]: H=mail-mw2nam10olkn2087.outbound.protection.outlook.com (NAM10-MW2-obe.outbound.protection.outlook.com) [40.92.42.87]:62109 X=TLS1.2:ECDHE_SECP384R1__ECDSA_SHA256__AES_256_GCM:256 CV=no rejected MAIL : prohibited sender domain There are these things to note from exim's log format [0]: * TLS was negotiated in both cases: `X` field * no `SNI` was provided in the blocked case * no client certificate valiation was done from exim to O365: `CV` field The `CV` field is the last thing I can control, but I don't believe that provides any authentication of valid email domains, only a lesser authentication that it's O365 connecting to me, which is already guaranteed by the IP ACLs. I appreciate the look, -- Alex [0] https://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Exchange 365 outbound connector being used as a relay
Hello all, This info may be better reserved for a Microsoft support ticket, but I figure there are a few people here who could help short circuit the process, or offer insight into my issue. My mail service currently uses Exchange 365 as the data store, with an exim outbound connector [0] hosted on AWS infra. The setup for outbound mail is as follows: MUA --> Exchange 365 MTA --> connector MTA --> Internet I've added ACLs on my connector to only accept port 25 TCP traffic from Exchange 365 IPs [1], and added an allowlist on my connector MTA to only accept mail for domains I own. During some log spelunking, I've received 3 curious entries (times UTC): Jan 28 10:38:40 webmail exim[2145158]: H=mail-mw2nam10olkn2087.outbound.protection.outlook.com (NAM10-MW2-obe.outbound.protection.outlook.com) [40.92.42.87]:62109 X=TLS1.2:ECDHE_SECP384R1__ECDSA_SHA256__AES_256_GCM:256 CV=no rejected MAIL : prohibited sender domain Jan 28 21:52:03 webmail exim[2281852]: H=mail-ma1ind01hn2225.outbound.protection.outlook.com (IND01-MA1-obe.outbound.protection.outlook.com) [52.100.187.225]:5171 X=TLS1.2:ECDHE_SECP384R1__ECDSA_SHA256__AES_256_GCM:256 CV=no rejected MAIL : prohibited sender domain Jan 28 23:22:58 webmail exim[2300338]: H=mail-bmxind01hn2226.outbound.protection.outlook.com (IND01-BMX-obe.outbound.protection.outlook.com) [52.100.219.226]:17370 X=TLS1.2:ECDHE_SECP384R1__ECDSA_SHA256__AES_256_GCM:256 CV=no rejected MAIL : prohibited sender domain Meaning that domains `outlook.com` and `mail.alokind.com` have managed to use Exchange 365 infrastructure to try and route email through my connector. My questions are: * Is this expected? * Are there any safeguards in place from preventing one tenant from using another tenant's connectors? * (!) `outlook.com` was somehow routed to my connector, how did that happen? * What are the suggested methods for preventing other tenants from using connectors with IP allowlists (i.e. are domain allowlists the way to go, are there other methods)? Thanks, -- Alex [0] https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-to-route-mail [1] https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
