[mailop] Office 365 Assistance
Hi everyone, I hope you are all well and staying healthy and safe. We’ve been working with The Home Depot on their Retool Your School Program (https://retoolyourschool.com/) for more than ten years now. Over the past year and especially the last few months, we are having a hard time getting their emails to the intended recipients with a lot of their messages going to junk. All the messages are going to HBCU’s (Historically Black College and Universities) and a lot of them are using Microsoft Office 365. We’ve begun to ask the colleges to mark their IP, domain, and email address as safe senders but it’s hard to reach everyone personally. The messages are not bouncing back, just ending up in Junk for a large majority of subscribers. This is a 100% opt-in program, and the list size is under 700 subscribers. They send out once to twice a week from December through May. All the colleges are competing for more than $500,000 in campus improvement prizes and many schools can’t participate because they aren’t receiving the emails. They have a dedicated IP address and custom DNS. It’s setup with SPF, DK, DKIM, DMARC, SNDS, JMRP, and a “List Unsubscribe” in the header. I’ve filled out the forms for Office 365 support and the IP isn’t blocked. I also filled out the Microsoft support form and the IP is also not blocked there or any indication through SNDS that there are any issues. If anyone on list may be able to help, the program would be greatly appreciative. Thanks, Michael Michael E. Weisel CTO / Deliverability Lead Gold Lasso (301) 990-9857 Corporate (240) 813-0174 Direct Dial ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail does not validate DKIM for forwarded messages?
I mean, you did originally send the spam message from one of your IPs. This is certainly an amplification attack from that fact, sure. I'm not sure that it's any different from previous replay attacks in that sense. If you take the "normal" way this would work, is that a spam message would go through a mailing list (presumably one that didn't break the dkim signature), then you would want most of the blame for the spam to go to the original sender, and not the mailing list. And presumably the reputation decline is due to us catching most of those messages as spam. Superficially, it looks like our system correctly handled this from a spam labeling perspective, and the collateral damage was mostly contained. I think it's a fairly complicated question about how to handle reputation in these instances, the reputation of your domain has been dinged due to its usage in spam. This more often happens in advertised domain reputations. In terms of correctly determining spam/not spam for our customers, the reputation is correct. The system does not rely on only a single reputation, however. In this case, there is also the SPF & IP reputations, which should be unaffected by the relay campaign. Theoretically, the system should be able to mostly compensate for messages coming from your system, which means the consequences would mostly accrue to forwarded messages. It's hard to guarantee that in an emergent system, of course. I do think this is useful to understand for ARC in regards to such a system, that "SPF" or "IP" reputation should be different from ARC-SPF or ARC-IP reputation. In terms of applicability to DMARC, however, the message is no less "legitimately authenticated", but that was already true because of the DKIM passing. And, of course, ARC (or DMARC) doesn't indicate spamminess directly, merely the source. And the source was your service, originally. Brandon On Tue, Feb 1, 2022 at 2:15 AM Edgaras | SENDER wrote: > > You can also see that the bodyhash (bh=) in the AMS and DKIM headers is > all the same, so the body itself didn't change? > No, the email body did not change. > > > Note that although ARC from gmail to gmail can be used to bypass a DKIM > failure, that's not what's happening here. > Yes, here it looks like if Gmail sees ARC (Gmail to Gmail) headers, it > trusts them completely: > - it ignores SPF permerror: > spf=permerror (google.com: permanent error in processing during lookup of > 921108683ccq405...@universidadebrasil.edu.br: > host.universidadebrasil.email not found) smtp.mailfrom= > 921108683ccq405...@universidadebrasil.edu.br > Return-Path: <921108683ccq405...@universidadebrasil.edu.br> > Received: from lingojam.com ([212.83.129.110]) > - ignores DNS/rDNS mismatch: rDNS for IP 212.83.129.110: > nelson-montoya.painmitigate.com, no A record. > - somehow thinks that the initial sending domain (sendersrv.com) should > be blamed, even though none of the intermediate IP addresses fall into > original domain's SPF, which contains -all > - and delivers spam to the inbox, no less. > > > A replay attack is the most likely explanation, yes. > It's a replay attack, but more sophisticated and dangerous due to use of > Gmail-Gmail ARC headers technique. > > We have since rotated our DKIM keys, added oversigning of From:To:Subject > headers 2 times, but I'm not sure that will be enough. > Could you or someone at Google take a closer look at this? We would be > happy to provide any data you need. > > > Best, > [image: Sender] Edgar Vaitkevičius, founder / CEO > ed...@sender.net > > > > > On Tue, Feb 1, 2022 at 2:52 AM Brandon Long wrote: > >> >> >> On Sun, Jan 30, 2022 at 4:21 AM Edgaras | SENDER via mailop < >> mailop@mailop.org> wrote: >> >>> Hello, >>> >>> We noticed in Google Postmaster Tools a lot of bad reputation IPs which >>> do not belong to us, and are actually forbidden from sending emails on our >>> behalf via SPF -all, yet Gmail thinks the messages from these IPs were >>> fully authenticated. >>> >>> After investigating some reports, it looks like a DKIM replay attack, >>> where Gmail does not validate the original DKIM signature (which includes >>> Message-ID:Reply-To:To: fields), and even ignores SPF permerror, if the >>> message contains ARC headers. >>> >>> Full headers below, any insights or suggestions would be appreciated: >>> >>> >>> Delivered-To: incident-repor...@gmail.com >>> Received: by 2002:ab0:340c:0:0:0:0:0 with SMTP id z12csp1291860uap; >>> Fri, 28 Jan 2022 15:34:21 -0800 (PST) >>> X-Google-Smtp-Source: >>> ABdhPJxGsLcEEUpdbgGs3QgR03Rr9huo0nZHyOFLB9HDsbANUeb9dkNH/PpuXMfWArmb2WtJtVZk >>> X-Received: by 2002:a17:902:cec8:: with SMTP id >>> d8mr10494650plg.98.1643412861553; >>> Fri, 28 Jan 2022 15:34:21 -0800 (PST) >>> ARC-Seal: i=2; a=rsa-sha256; t=1643412861; cv=pass; >>> d=google.com; s=arc-20160816; >>> >>> b=VU0Qf7i3UDk9cIk0HEQEv2hW46LmdHN1Z9UysluJsh4o1O1v5t12RrICEe8YlzFcZZ >>> >>>
Re: [mailop] 2 questions about BCC and mailing lists
Dnia 31.01.2022 o godz. 19:46:25 Grant Taylor via mailop pisze: > Remember, SMTP servers operate on the SMTP envelope. > > As such, the first SMTP server would send one copy directly to the > recipient's SMTP server and another copy to the MLM's SMTP server. I was assuming that first SMTP server and MLM's SMTP server are the same server, because otherwise - as I wrote - the question is not relevant at all in my opinion. In this case the SMTP server sends one copy directly to the recipient, and passes another one (usually via some internal mechanism, like aliases in case of mailman) to the MLM. MLM should send that copy to all list members, not paying attention to whoever may be in the "To:" header. > Mailman (2.x) has an option to not send additional copies to > subscribers if they are either To: or CC: recipients. This is (at > least) a per-recipient settings. (I don't know if there is a > mailing list / Mailman server default.) I think we should not talk here about "additional" copies as this may be misleading. "Additional" copy would be a third copy in this case (first one has been sent directly to the recipient, second one is from the mailing list and third one would be "additional", ie. sent to recipient directly by MLM in addition to the copy that comes from the mailing list). There is no such copy in mailman, AFAIK. This setting refers to whether the *second* copy (the one from the mailing list) should be send to the recipient or not (because mailman assumes that he already got his direct copy). Yes, you can specify a default for this setting when you create a mailing list in mailman. There is also a global default which is used as a default value for per-list default value :) But in my understanding that was not the OP's question - the question referred to the "direct" copy, not to the mailing list one... -- 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." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail does not validate DKIM for forwarded messages?
> You can also see that the bodyhash (bh=) in the AMS and DKIM headers is all the same, so the body itself didn't change? No, the email body did not change. > Note that although ARC from gmail to gmail can be used to bypass a DKIM failure, that's not what's happening here. Yes, here it looks like if Gmail sees ARC (Gmail to Gmail) headers, it trusts them completely: - it ignores SPF permerror: spf=permerror (google.com: permanent error in processing during lookup of 921108683ccq405...@universidadebrasil.edu.br: host.universidadebrasil.email not found) smtp.mailfrom=921108683ccq405...@universidadebrasil.edu.br Return-Path: <921108683ccq405...@universidadebrasil.edu.br> Received: from lingojam.com ([212.83.129.110]) - ignores DNS/rDNS mismatch: rDNS for IP 212.83.129.110: nelson-montoya.painmitigate.com, no A record. - somehow thinks that the initial sending domain (sendersrv.com) should be blamed, even though none of the intermediate IP addresses fall into original domain's SPF, which contains -all - and delivers spam to the inbox, no less. > A replay attack is the most likely explanation, yes. It's a replay attack, but more sophisticated and dangerous due to use of Gmail-Gmail ARC headers technique. We have since rotated our DKIM keys, added oversigning of From:To:Subject headers 2 times, but I'm not sure that will be enough. Could you or someone at Google take a closer look at this? We would be happy to provide any data you need. Best, [image: Sender] Edgar Vaitkevičius, founder / CEO ed...@sender.net On Tue, Feb 1, 2022 at 2:52 AM Brandon Long wrote: > > > On Sun, Jan 30, 2022 at 4:21 AM Edgaras | SENDER via mailop < > mailop@mailop.org> wrote: > >> Hello, >> >> We noticed in Google Postmaster Tools a lot of bad reputation IPs which >> do not belong to us, and are actually forbidden from sending emails on our >> behalf via SPF -all, yet Gmail thinks the messages from these IPs were >> fully authenticated. >> >> After investigating some reports, it looks like a DKIM replay attack, >> where Gmail does not validate the original DKIM signature (which includes >> Message-ID:Reply-To:To: fields), and even ignores SPF permerror, if the >> message contains ARC headers. >> >> Full headers below, any insights or suggestions would be appreciated: >> >> >> Delivered-To: incident-repor...@gmail.com >> Received: by 2002:ab0:340c:0:0:0:0:0 with SMTP id z12csp1291860uap; >> Fri, 28 Jan 2022 15:34:21 -0800 (PST) >> X-Google-Smtp-Source: >> ABdhPJxGsLcEEUpdbgGs3QgR03Rr9huo0nZHyOFLB9HDsbANUeb9dkNH/PpuXMfWArmb2WtJtVZk >> X-Received: by 2002:a17:902:cec8:: with SMTP id >> d8mr10494650plg.98.1643412861553; >> Fri, 28 Jan 2022 15:34:21 -0800 (PST) >> ARC-Seal: i=2; a=rsa-sha256; t=1643412861; cv=pass; >> d=google.com; s=arc-20160816; >> >> b=VU0Qf7i3UDk9cIk0HEQEv2hW46LmdHN1Z9UysluJsh4o1O1v5t12RrICEe8YlzFcZZ >> >> UziO53/5IMPjyEVGqLIEyLq0v0Dz5B4gtR94biUHiyIVYEEbn+20dr6ONrGE/IKsYBWD >> >> 2pBDc/D+Ppe4rBBhwQOckw9xK9f/l+RS1sbRU1AY2sW2hqJZzjSZUe0scWUGvbwB4RZl >> >> IS+F5z/T/ZLZ9s1v4JXmOoEnKu5b9oZ3XhJgc5EVYuAWJRFOrqIA7bRS8ISDJ+J/eYtJ >> >> fI9gWI5UkkM6qIgY/wFngV0FifP2Yauo/ts7su9FzFmxgHJdCLioQiFy4E6EEv8qN78c >> YrAA== >> ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; >> s=arc-20160816; >> >> h=date:date:content-transfer-encoding:mime-version:to:reply-to:from >> :subject:subject:message-id:dkim-signature:dkim-signature >> :delivered-to; >> bh=JYMTX3Rr+OZICy76j7DTKZeSFGH9xqoJ5IlXE//bwFY=; >> >> b=FdwHNKthXMrmoT3OevMII/o6PzRZR8UA6zIwTYBTTF2EA63hRW6yJVj7mQLBEyAQ6x >> >> WzjOhIf9zLeqzNYraveRpGQRcXUE/PqTaKDbzhTcqPfP9g82ea9dLhHgviwerKh1IhAp >> >> 3dri2wT2epRaIYnzEX2gMzmt8YiYjj3sHgvDDjg4Up4W1pYPmP4zx7N0UYxihu0B7eP6 >> >> 4igCLE8hfq1VPzWistU6uTe+HkSIupCpz8X1pQ41DcjLuwjfIsy18HXLH8yXqwyg37u5 >> >> +HX04rA5UlBMEOQnZhHneFGM7JrDU4Z7Yg6o/+uFkL7RfPE265N9CUS0YevgBX5D4IEY >> VwuA== >> ARC-Authentication-Results: i=2; mx.google.com; >>dkim=temperror (no key for signature) header.i=@ >> knowledgemodish.org.uk header.s=sender header.b=heNp+Lc9; >>dkim=pass header.i=@sendersrv.com header.s=smtp header.b=Ra7fdByf; >>arc=pass (i=1 spf=pass spfdomain=sendersrv.com dkim=pass dkdomain= >> sendersrv.com); >>spf=permerror (google.com: permanent error in processing during >> lookup of 921108683ccq405...@universidadebrasil.edu.br: >> host.universidadebrasil.email not found) smtp.mailfrom= >> 921108683ccq405...@universidadebrasil.edu.br >> Return-Path: <921108683ccq405...@universidadebrasil.edu.br> >> Received: from lingojam.com ([212.83.129.110]) >> by mx.google.com with ESMTP id >> j9si7146126plx.86.2022.01.28.15.34.21 >> for ; >> Fri, 28 Jan 2022 15:34:21 -0800 (PST) >> Received-SPF: permerror (google.com: permanent error in processing >> during lookup of 921108683ccq405...@universidadebrasil.edu.br: >> host.universidadebrasil.email not found) client-ip=212.83.129.110; >>
