[mailop] Incoming spam from outlook.com
This week, we've been getting quite a lot of carefully forged spam from outlook.com addressess, fully using their email infrastructure. What is your experience, is there point in putting effort into reporting it? Received: from smtp1.csc.fi (localhost.localdomain [127.0.0.1]) by localhost.localdomain (envelope-sender ) with ESMTP id 3BEM7Xf3015890 for ; Fri, 15 Dec 2023 00:07:35 +0200 Received: (from defang@localhost) by smtp1.csc.fi id 3BEM7IvH012400 for ; Fri, 15 Dec 2023 00:07:18 +0200 Received: from smtp1.csc.fi (localhost.localdomain [127.0.0.1]) by localhost.localdomain (envelope-sender ) with ESMTP id 3BEM7IId015829; Fri, 15 Dec 2023 00:07:18 +0200 Received: (from mail@localhost) by smtp1.csc.fi (8.14.4/8.14.4/Submit) id 3BEM7ITP015828; Fri, 15 Dec 2023 00:07:18 +0200 Received: from BL0PR02CU006.outbound.protection.outlook.com (mail-eastusazolkn1901.outbound.protection.outlook.com [52.103.11.0]) by smtp1.csc.fi (8.14.4/8.14.4/CSC) with ESMTP id 3BEM7F1i015812 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 15 Dec 2023 00:07:16 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ED4/pL0CafVHglmaDmvjHxVDN4EW9jGaMQR1VJYER8Bsa8swuMkxlZhTs65sAAt9eis5DBUBfn6cxwf8NTdxVZxuR2bhNTqcLnPguJCYqp623YQ+HGh/r3Bj7qkwCgrHoSChJ/EP/yQZMlDGmoU/Ly3LdSBZmEO9xBEV0IFue2vEey+aHblDvtFmImHsKci63Yedvu2omyr/zJr7Z5/FM613tKxE/BS0GDvsia7qHS/Qlap7rvCgIDERgv14Qg5OmtaQt3rm0tmQuI3L1dAr03WuJKYQC/LmC4BPYMOkfmJ++j14hURVSwqwDKQ2+GHfYs6hNlN+Br1ZzmRMCeNvvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=D+vYwBP6aADOQhZpYxFMSfCiOdzfInsqVrllavvDJEk=; b=n22tReCwEFnVZbea6M1d/XDPeerT366qXHUeAA1z2yMdkHAeCPQuSeRJf3zNZGndOCJza7xasD5Se8eEGONoyq+3YuF/OVVEW1Jyhdd1J85G8eKx7ices5ZjeXvz5aPqyYKEPfsOjl/f87pSaCd9KttLSOgXzU+s+gtt80aiRRokJdwlNfkaRuvS4rcjxjoS1X9ayUnhzQMLwFl+1nWO/JCXlQNpwHMs0GtWYdg4lXjOy4WNeasWYIyD9D8xuAJWRBIEgOzj6jnw3rsKbFhzN40d7UVreABzayjsnxxF7mwgiJpUjsk+qbrCHidoutcuzfVQbrP4esMIptGdRCwPng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D+vYwBP6aADOQhZpYxFMSfCiOdzfInsqVrllavvDJEk=; b=F68bS/eFYdcPZC1FKfvcJVO9sMoPgwzzbM6sctTJhpsEqVtgGULPtxlmPmmr12z1q5expAztRumFcFqb72vHAZ3L/Qz+sfSqyV4QtgUykmIsi9bIRiXxWmUVcHHrpBBy4lImm+76AUdxPL386FrTBHnWae12R+BXV18dxxziWdPIqBXx2ZW0etZnSJRCtq78ij1VU9L9tbTK0iygL8W2paDnLw5c7EXC2pwqWwG9uV8zKHOQK5Tzsvp8ePgdy2uBD0/pqfbeQa77JPL2dM8Orfe2cgZL2yeU5xl/0a+Y13h2+3g6mYjLCnhPIPYvKetEV6cwa60zd8KRoDByKeQWeQ== Received: from SA3PR05MB10372.namprd05.prod.outlook.com (2603:10b6:806:37d::18) by SA3PR05MB9668.namprd05.prod.outlook.com (2603:10b6:806:313::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7091.28; Thu, 14 Dec 2023 22:07:08 + Received: from SA3PR05MB10372.namprd05.prod.outlook.com ([fe80::b6f1:c6f7:359c:2f23]) by SA3PR05MB10372.namprd05.prod.outlook.com ([fe80::b6f1:c6f7:359c:2f23%3]) with mapi id 15.20.7091.028; Thu, 14 Dec 2023 22:07:07 + X-Mailer: MailBee.NET 12.3.1.667 From: "livshitsjemere1...@outlook.com" Subject: Sinkku UA-naiset ovat alueellasi! Reply-To: "livshitsjemere1...@outlook.com" Date: Thu, 14 Dec 2023 23:07:03 +0100 Message-ID: Content-Type: multipart/alternative; boundary="=_NextPart_000_44D3_27757235.EC7D78A2" To: Undisclosed recipients:; X-TMN: [t1N2pGILfQDQhYs+XuQIbsU9zMJ8MRod] X-ClientProxiedBy: VI1PR04CA0117.eurprd04.prod.outlook.com (2603:10a6:803:f0::15) To SA3PR05MB10372.namprd05.prod.outlook.com (2603:10b6:806:37d::18) X-Microsoft-Original-Message-ID: <1.b871d96563f8d1a21a98@DESKTOP-PKC9ISR> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA3PR05MB10372:EE_|SA3PR05MB9668:EE_ X-MS-Office365-Filtering-Correlation-Id: 011582c9-e06e-4d33-70fd-08dbfcf102e2 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info:
[mailop] Microsoft's block list?
Can someone shed light on a Microsoft/Outlook block list? Our hobby server (on upcloud.com) seem to have been blocked for quite some time now. At this time, SPF and DKIM should be correct for our outgoing messages. Is there anything to be done, apart from switching to some mail sender company instead of ourselves attempting a direct connection? 2023-11-15T08:27:37.762372+00:00 mail postfix/smtp[113710]: 7407B6274D: to=, relay=hotmail-com.olc.protection.outlook.com[104.47.18.97]:25, delay=0.29, delays=0.05/0/0.21/0.03, dsn=5.7.1, status=bounced (host hotmail-com.olc.protection.outlook.com[104.47.18.97] said: 550 5.7.1 Unfortunately, messages from [SERVERIPADDRESS] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [AM6EUR05FT032.eop-eur05.prod.protection.outlook.com 2023-11-15T08:27:37.743Z 08DBE4B9C5B508E7] (in reply to MAIL FROM command)) -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] outlook.com 421 try again later S77719
On 10/11/23 12:12, Andreas via mailop wrote: since a few hours we have problems with sending to Microsoft. We get hundreds of messages like in the subject with the reference to S77719. Also colleagues from other companies in germany are seeing the same in their logs. All mails that are blocked here are from Microsoft customers, but they are redirected through our servers. Trying to unblock the IP e.g. via https://sender.office.com/ shows that the IPs are not blocked. Microsoft had an about 16 hour period of time where their servers only gave a "451 4.7.500 Server busy" for their hosted domains. We saw these in the time range 2023-10-11T04:45/20:17+03:00, and in that time we had mails queued for about 300 different domains hosted with them. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ANY OVH Contact?
On 8/8/23 18:44, Anne Mitchell via mailop wrote: Does anyone have *any* contact at OVH? Reports to abuse@, and through the abuse page, have yielded nothing for this very unrepentant spammer. :-( Unless the situation has dramatically changed in the last year, OVH has no functioning abuse team. I block a majority of their nets from sending email, don't seem to getting any false positives. 5.196.0.0/16 15.204.0.0/17 51.38.0.0/16 51.68.0.0/16 51.77.0.0/16 51.83.0.0/16 51.89.0.0/16 51.195.0.0/16 51.254.0.0/15 54.37.0.0/16 54.38.0.0/16 135.125.128.0/17 147.135.0.0/16 151.80.0.0/16 162.19.128.0/17 188.165.0.0/16 -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Send emails over O365 to Google with a specific domain are rejected
On 8/7/23 03:06, Al Iverson via mailop wrote: If MS is using IPv6 to send the mail to Google, you might be in an extra difficult spot. Not everybody agrees/believes this, but in my experience Gmail is more quick to block IPv6-sent mail; they're more stringent about what they might let through versus IPv4. I can't imagine that's something you can control, but, hey, if I'm wrong and it is, it's worth checking. I concur, Google seems to think that if you are using IPv6 for transport you must be Teh Master of Teh Internet™, and it'll be trivial for you to get every single detail right in your messages. Then again, I can easily see how spammers would use IPv6 addresses to snowshoe their spam insertion. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else seeing email backed up to Microsoft -- only IPv6
On 25/10/2022 17.40, Frank Bulk via mailop wrote: We had it last night, too, but this morning seeing it again for hotmail.com, outlook.com, and live.com: Same here, with also the country-specific hotmail/live domains and msn.com (hardly surprisingly, as they are on the same servers). My temporary solution is to hardwire these for IPv4 delivery, which nicely cleared our queues. This does not scale. Unfortunately sendmail doesn't seem to have anything to do this on a permanent basis (ref: Claus Aßmann on comp.mail.sendmail), I'd be fine with IPv4 outgoing IPv4/IPv6 incoming. Also, Google seems to now be responding to a similar situation with a dsn=5.0.0 answer. How nice of them. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Feedback loops (was: The oligopoly has won.)
On 13/09/2022 02.44, Brandon Long via mailop wrote: Most of the major mailbox providers do have other feedback loops, many based on ARF, that can be used for this... Has anyone put together a good summary of available feedback loops, specially from big players? -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] gmail changes today?
On 08/06/2022 21.25, Brandon Long via mailop wrote: so the false positive rate for the new rule is better. It doesn't even need to be a new rule, maybe your reputation just decreased slightly and it now is below the threshold. I know of a couple of similar cases -- to me it seems Google's Bayesian heuristic (if there is such a thing) was over-zealous or something. It did not seem to matter if the outgoing messages passed SPF tests and/or had a correct DKIM signature: dsn=5.0.0, stat=Service unavailable. However, I haven't seen those today. Brandon, can you please look if your reject rates were suddenly up for a while, I'm sure there are statistics available? -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] MacOS Contacts and automatically collected email addresses
On 05/11/2021 16.18, Marcel Becker via mailop wrote: Now it's quite possible that other contact sources you have configured on our Mac are in fact doing what you are describing. (ie If you have Google Contacts configured and Google might be doing interesting things). Also note that Apple Contacts will "merge" cards from multiple sources if it thinks they are the same. But that is purely "virtuel" and you can "unlink" them. That too should not have any impact on anything else. There may indeed be other variables and devices at play here — eg. I have a suspicion that Siri, Google Assistant or Android devices do this kind of things to be "helpful". We are a Linux/MacOS/Windows house, with also the option for some BYOD, so there is room for all kinds of interactions here. However, whatever the cause, the end result (which we repeatedly have seen in action) is same: in the user's Mac Mail email directory, the "canonical" email address for an user suddenly gets bumped by another address. This plays havoc with calendar functions, as I noted. But now we really completely left the topic of "mailop" True, but these days calendars and contacts have unfortunately become a part of the "email user experience", like it we or not. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] MacOS Contacts and automatically collected email addresses
This is kinda peripherally connected to mail system operations, but probably still interesting. I've opened a feedback ticket to Apple about the address collecting behavior of the MacOS Contacts application, that causes issues through interaction with their other products Mac Mail and Calendar. Contacts automatically collects email addresses from email messages and other sources into the user's address book. It also merges these collected addresses under single entries using somewhat poorly documented heuristics which are not adjustable by the end user. This becomes a problem when Contacts changes its opinion of the "canonical" address of an user: users start receiving email messages to some secondary address that Contacts has (for somewhat unclear reasons) decided is the same as their main email address. This also becomes a plague on other Mac users when receiving email messages where this change has occurred, as their Contacts then also squirrel away the newly seen email address, possibly also changing this be the canonical address for that user. For example, the canonical address firstname.lastn...@domain.com could suddenly change into usern...@server.domain.com in users' address books, through no action of their own. This also becomes a clear bug when this kind of unexpected canonicalization change gets processed by calendar functions. Calendar server end code is not forgiving of attempts to change eg. the organizer of a meeting, and when a calendar change gets rejected by the server end, the client calendar becomes unsynchronized with the server view and any other meeting participant's view. Email address canonicalization should never be attempted on calendar entry email addresses, but the root error in this case was in the Contacts application code that caused the change. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Locally hosted anti-spam solution recommendations?
We're currently running Roaring Penguin CanIT as our mail frontend, and have been given an end-of-life notice from the new owners: https://go.zixcorp.com/index.php/email/emailWebview?md_id=21715 So, now we're looking for a good frontend with antispam functions. CanIT is a set of open source software (Sendmail, Spamassassin, blocklists, ClamAV, opendkim etc) packaged with a nice web gui interface to control it all on a locally hosted Linux server. And that's basically what we'd also need to replace it. Some random cloud hosting spam solution is not a viable option, we're a Finnish government owned contractor. Also we need to know (if need be) what happened to each and every email coming and going, not "perhaps our proprietary spam system ate it, we won't tell you" as so many of these cloud solutions seem to be. Any recommendations? -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Firefox Phishing Protection says 413: Your client issued a request that was too large.
On 14/10/2021 17.31, Al Iverson wrote: > Otto! Long time no talk. Hope you're doing well. :) > > If it's any consolation, Gmail thinks that your post to Mailop is a > phish, so perhaps the bad domain made it to the Google Safe Browsing > blacklist, at least. :) Interestingly enough, I sent the message with the URL edited to start with hxxps:// so I assumed it couldn't end up triggering phishing filters. Little did I know :-D -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Firefox Phishing Protection says 413: Your client issued a request that was too large.
We received some phising emails, and when you access the phishing site redirector hxxps://googleweblight.com/i?u=sso-webmailsrvr-s334bggbh.pages.dev?user=em...@example.com you will be redirected to a website using such a long URL (about 15k) that when you try to report it to Firefox Phishing Protection it fails with 413: Your client issued a request that was too large. This URL contains a base64-encoded html file, and without it trying to access the site just produces a "this account has been suspended" message. I don't doubt this is the reason why they chose to do it like this. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF prevents enabling IPv4+IPv6?
On 02/03/2021 18.28, John R Levine via mailop wrote: > On Tue, 2 Mar 2021, Otto J. Makela wrote: >> I read this as meaning most implementations will let you only have >> two NOERRORs, and then it's game over. As I said, I doubt SPF was >> intended to cause this side effect. > > Hm, missed that, it does seem wrong. > > On the other hand, if you're going to support IPv6, it seems to me > that it you put host names in your SPF record, those names should > have both A and records. As other people have pointed out, > using the IP addresses is often a better idea anyway. In this case, we just host a server for this customer domain, and generate emails for them from it. SPF has been set appropriately. Because the customer only has IPv4 email servers, WE cannot send out email through our standard multi-protocol support email servers. If the other email services in the SPF at some point go IPv6 this might change, but it's a bit strange we have to account for this. This same effect also precludes any other servers in the SPF from ever wanting to go to IPv6. Unintended consequences, as I said. I'm kinda disappointed that the IPv4/IPv6 "never the twain shall meet" divide is still so strong, just treating names as symbols to be resolved (by whatever protocol) would have made so much more sense. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF prevents enabling IPv4+IPv6?
On 02/03/2021 10.28, Otto J. Makela via mailop wrote: > Unfortunately, RFC 7208 section 4.6.4 DNS Lookup limits also states: > >As described at the end of Section 11.1, there may be cases where it >is useful to limit the number of "terms" for which DNS queries return >either a positive answer (RCODE 0) with an answer count of 0, or a >"Name Error" (RCODE 3) answer. These are sometimes collectively >referred to as "void lookups". SPF implementations SHOULD limit >"void lookups" to two. An implementation MAY choose to make such a >limit configurable. In this case, a default of two is RECOMMENDED. > > I read this as meaning most implementations will let you only have > two NOERRORs, and then it's game over. As I said, I doubt SPF was > intended to cause this side effect. This being the case, I would probably need to configure sendmail to prefer IPv4 for outgoing mail. Does anyone have a ready recipe for sendmail-8.14.7-6.el7 handy, as the methodology seems to have changed quite a lot over the versions? (I can of course force it for individual domains using mailertable, but this once again doesn't really scale) -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF prevents enabling IPv4+IPv6?
On 01/03/2021 18.41, John Levine wrote: > In article <8a937890-bfd7-8ee9-3818-063c12d68...@iki.fi> you write: >> } until match IP address connecting us or error count exceeded >> >> which means the error count very easily gets exceeded if your >> email server uses IPv6 and few (or none) of the other host names in >> the SPF record have such addresses. > > That would be a fairly broken implementation. RFC 7208 sec 4.3. says > > If the is malformed (e.g., label longer than 63 characters, > zero-length label not at the end, etc.) or is not a multi-label > domain name, or if the DNS lookup returns "Name Error" (RCODE 3, > also known as "NXDOMAIN" [RFC2308]), check_host() immediately > returns the result "none". DNS RCODEs are defined in [RFC1035]. ... > > If a name has an A record but no record, an lookup returns > success with no records, often called NOERROR. If your DNS library > is returning NXDOMAIN in that situation, you need to find a better > library ASAP. Unfortunately, RFC 7208 section 4.6.4 DNS Lookup limits also states: As described at the end of Section 11.1, there may be cases where it is useful to limit the number of "terms" for which DNS queries return either a positive answer (RCODE 0) with an answer count of 0, or a "Name Error" (RCODE 3) answer. These are sometimes collectively referred to as "void lookups". SPF implementations SHOULD limit "void lookups" to two. An implementation MAY choose to make such a limit configurable. In this case, a default of two is RECOMMENDED. I read this as meaning most implementations will let you only have two NOERRORs, and then it's game over. As I said, I doubt SPF was intended to cause this side effect. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] SPF prevents enabling IPv4+IPv6?
Due to never actually reading the sources, and a careless browsing
of the SPF specs, I always assumed the algorithm was something like:
retrieve email sender
retrieve IP address used to connect to us
retrieve & parse appropriate SPF txt record from DNS
repeat for each ip / mx / name / include in SPF {
resolve names into IPv4 or IPv6 addresses (getaddrinfo)
} until match IP address connecting us or error count exceeded
but actually the algorithm is closer to
retrieve email sender
retrieve IP address and protocol used to connect to us
retrieve & parse appropriate SPF txt record from DNS
repeat for each ip / mx / name / include in SPF {
resolve names with A or queries, depending on protocol
} until match IP address connecting us or error count exceeded
which means the error count very easily gets exceeded if your email
server uses IPv6 and few (or none) of the other host names in the SPF
record have such addresses.
https://tools.ietf.org/html/rfc7208
I guess you could try to avoid this by mucking with the SPF record,
sorting the hosts which DO have IPv6 to the beginning. But you could
never be really sure what this entitles, since includes might expand
to anything. Also, if you're just sending email for someone else,
this simply doesn't scale.
I believe in practical terms this means, no sensible service provider
would ever switch over to using a dual-protocol IPv4+IPv6 email hosts,
since your emails might not go through in tricky-to-debug ways.
I doubt SPF was intended to cause this side effect.
I guess wiser minds than me already figured all this out?
--
/* * * Otto J. Makela * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 0100 01001011 * * * * * * */
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Protection.outlook.com SPF hoops to jump for IPv6
On 27/10/2020 09.54, Otto J. Makela via mailop wrote: > On 23/10/2020 23.42, John Levine wrote: >> In article you write: >>> When sending messages to a *.mail.protection.outlook.com host via IPv6, >>> our mail host gets the following email status: >>> >>> #4.7.26 SMTP; 450 4.7.26 Service does not accept messages sent over IPv6 >>> [2001:708:10:6004::22] unless they pass either SPF or DKIM validation >>> (message >>> not signed) (S825). [DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com] >> >> FWIW, Gmail has had the same rule for a long time, all IPv6 mail must >> be validated with SPF or DKIM, so you're better off fixing whatever is >> wrong. >> >> Do you know what address it's trying to send mail from? It looks to me like >> your SPF record allows 2001:708:10:6004::22 and ::14 > > That's just it: as I said in my original message, the mail in this case is > coming from smtp.sdn.csc.fi [2001:708:10:6004::22]. > > I'm a bit at loss to what's wrong. Do they require SPF softfail instead > of neutral, that is, replace "?all" with "~all" in the record? If that's it, > pretty much a misuse of SPF, I'd say. So, nobody has any further comments to the required hoops? I'm beginning to suspect the "either...or" in the message below should really be "both...and". Microsoft doesn't have anyone here? Remote Server returned '' -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Protection.outlook.com SPF hoops to jump for IPv6
On 23/10/2020 23.42, John Levine wrote: > In article you write: >> When sending messages to a *.mail.protection.outlook.com host via IPv6, >> our mail host gets the following email status: >> >> #4.7.26 SMTP; 450 4.7.26 Service does not accept messages sent over IPv6 >> [2001:708:10:6004::22] unless they pass either SPF or DKIM validation >> (message >> not signed) (S825). [DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com] > > FWIW, Gmail has had the same rule for a long time, all IPv6 mail must > be validated with SPF or DKIM, so you're better off fixing whatever is > wrong. > > Do you know what address it's trying to send mail from? It looks to me like > your SPF record allows 2001:708:10:6004::22 and ::14 That's just it: as I said in my original message, the mail in this case is coming from smtp.sdn.csc.fi [2001:708:10:6004::22]. I'm a bit at loss to what's wrong. Do they require SPF softfail instead of neutral, that is, replace "?all" with "~all" in the record? If that's it, pretty much a misuse of SPF, I'd say. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Protection.outlook.com SPF hoops to jump for IPv6
We have a customer (Finnish Academy aka.fi) who use our services to send out emails through our server smtp.sdn.csc.fi. Unfortunately, Outlook.com seems to have added more hoops for us to jump through. When sending messages to a *.mail.protection.outlook.com host via IPv6, our mail host gets the following email status: #4.7.26 SMTP; 450 4.7.26 Service does not accept messages sent over IPv6 [2001:708:10:6004::22] unless they pass either SPF or DKIM validation (message not signed) (S825). [DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com] SPF for aka.fi is, as far as I can tell, correct albeit non-restrictive. Before I start randomly making changes (like adding DKIM etc), does anyone have ideas? https://mxtoolbox.com/SuperTool.aspx?action=spf%3aaka.fi=toolpage https://www.spf-record.com/spf-lookup/aka.fi?ip=2001:708:10:6004::22 The latter test gives me a slightly germanic error about non-restrictiveness. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] OVH Bulk Mailer? Anyone know this one?
On 21/05/2019 12.37, Otto J. Makela via mailop wrote: > Is there any point in receiving any email from any OVH space, > since discussions on this list would seem to indicate they have > no functioning abuse enforcement? > > Numerous netblocks registered to them [...] > seem to be permanent spammer havens. Has the situation improved at all in the last year, or shall I keep denying access for OVH large blocks? 5.135.0.0/16 5.196.0.0/16 51.38.0.0/16 51.68.0.0/16 51.75.0.0/16 51.77.0.0/16 51.83.0.0/16 51.89.0.0/16 51.91.0.0/16 51.178.0.0/16 51.254.0.0/15 54.36.0.0/16 54.37.0.0/16 54.38.0.0/16 91.121.0.0/16 91.134.0.0/16 92.222.0.0/16 145.239.0.0/16 147.135.128.0/17 149.202.0.0/16 164.132.0.0/16 176.31.0.0/16 188.165.0.0/16 193.70.0.0/17 213.32.0.0/17 -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] OVH Bulk Mailer? Anyone know this one?
Is there any point in receiving any email from any OVH space, since discussions on this list would seem to indicate they have no functioning abuse enforcement? Numerous netblocks registered to them like 51.77.44.64-51.77.44.127 described as "Failover IPs / Legacy" seem to be permanent spammer havens. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
