Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Jarland Donnell via mailop]

To add +1 experience to this, I've been seeing it intermittently. Some 
of my customers who lack SPF absolutely cannot deliver mail to Gmail, 
100% rejection due to lack of authentication. Others, not so much. I 
can't pretend to know what the criteria is for falling into the former, 
but it hasn't been a large number of domains we've noticed it on.


On 2022-04-19 02:20, Andre van Eyssen via mailop wrote:

Hi all,

A week or so ago I was dealing with some domains that were nearly 100%
bouncing on delivery to gmail. It turns out that the domain owners had
made registrar/DNS hosting changes and while they managed to create
the MX records correctly, they left out the SPF.

A little testing shows that gmail appears to be rejecting all mail
from domains with no SPF record. Having them create the SPF record
returned their domains to deliverability in about an hour.

Just a heads-up!

Andre.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Deep dive into the dayjob's mail servers and SPF/DKIM tightening

[Dan Mahoney via mailop]

Dayjob (you know who) has been doing DKIM/DMARC for a few years now, but at the 
hinting of some knowledgeable users on this list, there were a few discoveries 
we made.  

We use dmarcian, and I also dogfood the same service for my personal domain.  
They’ve been good to us and were involved in the standards process.

Here’s a few discoveries I’ve found in the process of trying to 
torque-every-bolt to spec.  It is a long-tail problem.  Maybe these things will 
help you, too.

1) Our dmarc reports themselves were not being DKIM signed.  In postfix land 
this is because there’s a different milter setting for things that call the 
sendmail command line, than that for things that talk on 25.

2) There are some people on our mailman lists who are probably forwarding their 
stuff to freemail providers.  This makes our domain name look 
frequently-spoofed, and it makes their IPs look like frequent spoofers of that 
domain.  My guess is that they’re doing some procmail/formail thing that breaks 
the DKIM signatures.  ARC-sealing would not help this, at least on our end.  
The forwarders would have to do the arc-sealing.  I can “fix" this problem by 
setting p=reject, but I’ve attempted to reach out to them instead :)

3) SPF records can get really tangly.  We at one point had a /16, and that was 
causing some not-ours-anymore IPs to be listed under our administrative control 
in postmaster tools.  (Does that mean a new owner of those ips was spoofing our 
domain specifically?  I don’t think so). 

3a) In narrowing that down to discrete blocks, I finally had to (“break out “ 
my spf record ” “to multiline format") in my zone file which does afford some 
readability benefits and make version control a little easier, but there’s 
still theoretical max-length rules, and max-lookup rules to be aware of.

4) China just sends a metric ton of garbage, some of it with made-up 
subdomains.  It caused me to go through the various sending subdomains we *do* 
have, make sure they had their own dmarc policies, then drop a sp=reject at the 
root domain.

5) Our mailman list was only signing things from its own lists.foo.org 
 subdomain (it delivers directly, not via our border 
MX).  While it’s a minor abuse of power to have us sign anything from our 
domain, we also post to and participate on those lists *a lot*, so 
percentage-wise, this affects IP reputation quite a bit. (SPF always passes 
which is an equal "abuse of power").  

5a) For this, the correct solution *would* be getting openarc running so 
everyone not under our domain can benefit from it.  Dmarcian and friends don’t 
give me much visibiity into how our arc sealing of other domains is being 
respected, since they’re not our administrative domains.

-Dan___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SendGrid, what happens when you don't address the root problem (Indeed Phishing)

[Robert L Mathews via mailop]

On 4/19/22 1:46 PM, Atro Tossavainen via mailop wrote:


They're definitely the biggest ESP in our spamtraps, have been
for more than a year solid.


Yep. As most probably remember, someone from SendGrid came on the list 
for a while, made some noises about cleaning things up, and then 
disappeared.


SendGrid is still a cesspit of forged mail, phishing, and B2B "harvested 
from LinkedIn" spam. Spam complaints result in listwashing at best. They 
clearly don't care, because some very basic rules would eliminate quite 
a bit of it (like rate-limiting and spot-checking new customers who send 
from addresses at domain names registered within the last 24 hours, such 
as "indeed-verify.com").


I'm sure someone else from SendGrid will be back on here within a year 
or so claiming they've just been hired to clean things up, make a few 
more noises for a month, and disappear again.


--
Robert L Mathews
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[John Levine via mailop]

It appears that Andre van Eyssen via mailop  said:
>A little testing shows that gmail appears to be rejecting all mail from 
>domains with no SPF record. Having them create the SPF record returned 
>their domains to deliverability in about an hour.

I found the same thing for friends who were complaining that Gmail
was rejecting their mail.  It took a couple of tries saying to add
exactly this TXT record at that name, but once they did, the mail
flowed again.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SendGrid, what happens when you don't address the root problem (Indeed Phishing)

[Atro Tossavainen via mailop]

> You think we would be done with SendGrid conversations two years ago..

No such thing.

> And two hours later, a phishing attempt from a SendGrid IP hit the
> spam folder...
> 
> Return-Path: 
> Received: from wrqvndzq.outbound-mail.sendgrid.net (HELO
> wrqvndzq.outbound-mail.sendgrid.net) (149.72.45.228)

Confirmed, seen here too.

> From: Verify 2FA <2...@indeed-verify.com>
> Subject: Indeed for Employers - Your Account Required 2FA Verification.
> Reply-To: 2...@indeed-verify.com

X-Entity-ID: Z9o86N06AN6V9pUxLwsPGQ==

(even though "26471268" should be more than enough)

> One more reason to flag all of SendGrid shared servers as spam?

They're definitely the biggest ESP in our spamtraps, have been
for more than a year solid.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] SendGrid, what happens when you don't address the root problem (Indeed Phishing)

[Michael Peddemors via mailop]

You think we would be done with SendGrid conversations two years ago..

Was just reading on Twitter how Indeed is the most 'phished' brand now, 
and was just thinking .. strange, we never see that..


And two hours later, a phishing attempt from a SendGrid IP hit the spam 
folder...


Return-Path: 
Received: from wrqvndzq.outbound-mail.sendgrid.net (HELO 
wrqvndzq.outbound-mail.sendgrid.net) (149.72.45.228)


...

Received: by filterdrecv-5645d9c87f-qkrn6 with SMTP id 
filterdrecv-5645d9c87f-qkrn6-1-625F0F6C-31

2022-04-19 19:37:16.543027278 + UTC m=+1115583.921800690
Received: from MjY0NzEyNjg (unknown)
by geopod-ismtpd-3-2 (SG) with HTTP
id J2ChZWkeQI2kQOw2SfikRg
Tue, 19 Apr 2022 19:37:16.293 + (UTC)
Content-Type: multipart/alternative; 
boundary=f459e59497c8d2c167f2e66d0da8a114fe36aff1995e4b1ca148b875f88b

Date: Tue, 19 Apr 2022 19:37:18 + (UTC)
From: Verify 2FA <2...@indeed-verify.com>
Mime-Version: 1.0
Message-ID: 
Subject: Indeed for Employers - Your Account Required 2FA Verification.
Reply-To: 2...@indeed-verify.com

One more reason to flag all of SendGrid shared servers as spam?


--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] Re: FYI - Google/Gmail hard enforcing SPF presence

[Jaroslaw Rafa via mailop]

Dnia 19.04.2022 o godz. 15:34:07 Kevin A. McGrail via mailop pisze:
> 
> My argument is since you can't join Google's postmaster tools until
> you have SPF or DKIM, well that sort of answers it for you from
> Google's perspective:

Google Postmaster Tools is of no use anyway if you are a small sender. For
me it always shows that there is not enough data to display anything.
-- 
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] [External] Re: FYI - Google/Gmail hard enforcing SPF presence

[Kevin A. McGrail via mailop]

While you are likely right about RFCs, general mail administrator 
hygiene like having rptr's, etc. is something we've all had to work on 
since the days of AOL being the 1000lb gorilla and enforcing postmaster 
guidelines.  RFCs typically codify real-world practices not drive them.


My argument is since you can't join Google's postmaster tools until you 
have SPF or DKIM, well that sort of answers it for you from Google's 
perspective:


https://support.google.com/mail/answer/9981691?hl=en

On 4/19/2022 3:27 PM, Jaroslaw Rafa via mailop wrote:

  If it doesn't, SPF check should be
ignored. There is no RFC that says you MUST have a SPF record.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Jaroslaw Rafa via mailop]

Dnia 19.04.2022 o godz. 11:17:54 Scott Mutter via mailop pisze:
> 
> I'm a little surprised people are this upset.  Google's using SPF for what
> it's actually meant for - and yet people are upset because they are doing
> that?

No. "Using SPF for what it's actually meant for" would be honoring what the
domain owner has decided, not attempting "to know better". If domain has a
SPF record, it should be enforced. If it doesn't, SPF check should be
ignored. There is no RFC that says you MUST have a SPF record.
-- 
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] [External] FYI - Google/Gmail hard enforcing SPF presence

[Bill Cole via mailop]

On 2022-04-19 at 10:54:17 UTC-0400 (Tue, 19 Apr 2022 10:54:17 -0400)
Kevin A. McGrail via mailop 
is rumored to have said:

Interesting note that we also saw this a few weeks ago too and had to 
add DKIM to get mail to work to domains that only had SPF.


I'm very glad for that warning.

I have not seen that in production yet, but do have a tech debt ticket 
for adding DKIM signing to ~40 hosted domains. I guess it's likely to 
REALLY matter soon. Sure am glad for having done pilots and standing up 
needed infrastructure.


IMHO the worst 'tax' imposed on smaller mailbox/business email providers 
by the big guuys is via DKIM & DMARC enforcement. SPF records are a fast 
set-and-forget magic handshake. There's apparently no limit to how much 
work one can put into getting DKIM+DMARC working well, as there's always 
some weird breakage lurking out there somewhere.



On 4/19/2022 3:20 AM, Andre van Eyssen via mailop wrote:
A little testing shows that gmail appears to be rejecting all mail 
from domains with no SPF record. Having them create the SPF record 
returned their domains to deliverability in about an hour.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Laura Atkins via mailop]

> On 19 Apr 2022, at 18:53, Tim Düsterhus via mailop  wrote:
> 
> On 4/19/22 16:57, Laura Atkins via mailop wrote:
>> We just did 2 tests, one with an email that violated half a dozen best 
>> practices and one that has a SPFSoftfail (with no DKIM).
> 
> I believe you accidentally pasted the same test twice, the headers look 100% 
> identical to me.

Oops. 

Really badly formatted email: 

Delivered-To: wttwla...@gmail.com
Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id i38csp2956940pzk;
Tue, 19 Apr 2022 07:44:59 -0700 (PDT)
X-Google-Smtp-Source: 
ABdhPJznmP9P9y29YlGiaLzZTxw0NXW8HUbBKmVBAeegvyAXSFlmXFYoYl/b2Xkgh7yVLnt6UuK7
X-Received: by 2002:a5d:6d03:0:b0:20a:7af0:380f with SMTP id 
e3-20020a5d6d0300b0020a7af0380fmr11823278wrq.148.1650379498973;
Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1650379498; cv=none;
d=google.com; s=arc-20160816;
b=oAA3r/bEkAyRjN7ZL7C2R9PNSNlehAqTYFpiww5W9ojBBIcPeXwmLRZiMZr3B/Ug5d
 BiJezi7mylKI+UO2ywcAG7h1jmTAeizH3j1ghCzukMp2uh3w3oHZ64R+3JAAajACtRcH
 lc1BkI/RLdsj7uv7tU3ECElQPX80PC1/hPzxYzc8Si/U761BLX3gVgK+QBeie1HX81JO
 HJFtAqVxp/AaVFH4qZuScWJGC23wN5C2Q0pNIytEAc3xk2momvTNrNvYERAqPlYfz32c
 9Li7Yh330SYhCfGwNrCM0tWZJN7/G9YFDPRyWbWh8j71Xqnx3M7XiNrXGPIbcBrvpoNw
 INbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
h=message-id:subject:from:to:date;
bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=;
b=P1PMZlNCzI7TENQ2QO8kaSWDTckbB3jDkrrzxUbjxzgJ/SfGFjHSJpyFttLPHKnatk
 pTDj/P5r07tRG7lQ4msWgKZocbyj3y5j6ZNqWRgs189MgDCAb1u533ZJlmRyzWZi2n/3
 u50p14IatncLBfPrcxOwMACDBzPRd8P2h72VGcG5V9cRz27WziJmVOxtVEUJk5Hd+c2Z
 KoQ+Uzf/lRkGwcKo0MDcQ6qMG3swCdMioHmG4N26/VVOBSNDVbRJZ4J0KR+4TZNO4NlT
 gZZKMuWeQvr54C+rtg8ht/OekVrhbksGrKWNoicG78FwORNoUINzJVMAdxhVAWzvWAPq
 Vv2g==
ARC-Authentication-Results: i=1; mx.google.com;
   spf=neutral (google.com: 185.97.236.152 is neither permitted nor denied 
by best guess record for domain of steve@sliver) smtp.mailfrom=steve@sliver
Return-Path: 
Received: from sliver ([185.97.236.152])
by mx.google.com with ESMTP id 
p7-20020adfe60700b00203e90194c2si8108892wrm.582.2022.04.19.07.44.58
for ;
Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
Received-SPF: neutral (google.com: 185.97.236.152 is neither permitted nor 
denied by best guess record for domain of steve@sliver) 
client-ip=185.97.236.152;
Authentication-Results: mx.google.com;
   spf=neutral (google.com: 185.97.236.152 is neither permitted nor denied 
by best guess record for domain of steve@sliver) smtp.mailfrom=steve@sliver
Date: Tue, 19 Apr 2022 15:44:58 +0100
To: wttwla...@gmail.com
From: steve@sliver
Subject: test Tue, 19 Apr 2022 15:44:58 +0100
Message-Id: <20220419154458.051019@sliver>
X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/

This is a test mailing

One that mostly conforms to the RFCs. 

Delivered-To: wttwla...@gmail.com
Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id i38csp2961601pzk;
Tue, 19 Apr 2022 07:50:37 -0700 (PDT)
X-Google-Smtp-Source: 
ABdhPJzdelAB/vcgsTFh7OdsgiN0lLCP24pEqpJQB3u5+BeRw0wJWFERr07eWGD1nqmfVWBYzp/g
X-Received: by 2002:adf:f943:0:b0:203:b456:c71d with SMTP id 
q3-20020adff94300b00203b456c71dmr12103183wrr.568.1650379836971;
Tue, 19 Apr 2022 07:50:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1650379836; cv=none;
d=google.com; s=arc-20160816;
b=u9bUGGpAm++qienOOtsdojZxEDHIcDQA2kuYs40BSeleAFtgg/mekwNjXxz0MzGQ/w
 a51PSfokRCPDxcDKgcOU7TdlSIVHI4elF1fAKLwHDzwYQfAUZS7zRumHYQ89qD0JqKPm
 b0Ua3iEgDbDEHZEdUZJmEnh7MojFMh7LSu/jM38+mq/rWyneDhZwXFDuaHza7tfqYvNZ
 Vayo2fPrwDGYCxzPZFnU9phFhsU4owWslKy2cL9fQ8BHfA3RqSS2b6UOTFwYXoexp3GR
 ZdUPB4U/D/fD1+zZi7Pyk/FKxkXECzyMlzS0ltyOu813nqikPJu2w6PtrMBucFtz3sDq
 rxsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
h=message-id:subject:from:to:date;
bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=;
b=0kz6ln2tXtO/lp0uY8fdTNdWTC//vgV8edm8edlqR9E1Glh4C9dIW1nN/GARf+bwZ7
 5jqDTuQBbeeCeBa6f2h5Qa+/EnTscHcgATJtdC8Vlw8KCp1zbdIVPzBUdPzidAcx0GdO
 Dzt+TpkZAHsmT32xR47of9FRroHppwyyMYfDkgPTIiMQNdwi5k6v7QfCu39SGML3v9LO
 fLzrohKxQ3C2fXzxM6E3S/AzbGZEDC4Dp8PValm2ijSirasPxiseExlquViTXf3kf2M+
 NMtk2A5Ozs2ySwLj+SGzA81n8SbqaHneLBetFjou5aqy0Ty3hZrzht9Z3yo9bYDeySGA
 lhyw==
ARC-Authentication-Results: i=1; mx.google.com;
   spf=softfail (google.com: domain of transitioning 
st...@wordtothewise.com does not designate 185.97.236.152 as permitted sender) 
smtp.mailfrom=st...@wordtothewise.com
Return-Path: 
Received: from m.wordtothewise.com ([185.97.236.152])
by mx.google.com with ESMTP id 
c8-20020adffb4800b00206174b2125si8483775wrs.338.2022.04.19.07.50.36
for ;
Tue, 19 Apr 2022 07:50:36 -0700 (PDT)

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-19 at 02:10:06 UTC-0400 (Tue, 19 Apr 2022 08:10:06 +0200)
Hans-Martin Mosner via mailop 
is rumored to have said:


Am 18.04.22 um 21:02 schrieb Bill Cole via mailop:

On 2022-04-18 at 13:32:07 UTC-0400 (Mon, 18 Apr 2022 12:32:07 -0500)
Larry M. Smith via mailop 
is rumored to have said:


...
I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, 
or Microsoft do NOT re-queue messages after receiving a 5xx response 
-- Qmail does.


Did you mean "GMail?"

FWIW, I've not seen GMail (or Qmail) do that. Do you know how to 
reproduce it?


I have a current sample where GMail did this. They apparently do it 
for 5.7.1 responses to DATA only, and not always, but I don't have 
complete statistics for this.


Thank you so much for the details. It gives me something to look for in 
logs.


Here are the log entries for the recent run (which were rejected after 
DATA due to a known-spammer body pattern, which is one possible way to 
keep the ever-changing GMail 4-1-9ers somewhat in check.) Note that 
identical message ID provies that this isn't the spammer repeatedly 
trying to get his/her fraud message across, but Google trying to force 
the spam down our throat :-)


Hypothetically possible that the spammer resubmitted the same message 
with existing MID 11 times. (unlikely)


Hypothetically possible that this indicates envelope splitting of some 
sort, i.e. same message being sent to different recipients on each try. 
That would be a natural approach to having recipients in multiple 
domains. It would also happen if the original had n recipients but the 
receiver forces one-at-a-time transfer by 4xx-ing recipients 2 through 
n.


I have investigating to do...



Apr 18 19:43:34 mail postfix/cleanup[23243]: 7D1D4120D85: 
message-id=
Apr 18 19:50:22 mail postfix/cleanup[24996]: 7C34B120D72: 
message-id=
Apr 18 20:13:48 mail postfix/cleanup[27908]: 8189A120D84: 
message-id=
Apr 18 20:40:41 mail postfix/cleanup[459]: 059EB120D0C: 
message-id=
Apr 18 21:25:48 mail postfix/cleanup[15781]: DAAD7120D74: 
message-id=
Apr 18 22:16:56 mail postfix/cleanup[28107]: 43595120D0C: 
message-id=
Apr 18 23:43:07 mail postfix/cleanup[14675]: 0F230120D30: 
message-id=
Apr 19 01:13:13 mail postfix/cleanup[25151]: 50B47120D0C: 
message-id=
Apr 19 02:44:45 mail postfix/cleanup[9739]: 23C56120D0C: 
message-id=
Apr 19 04:30:16 mail postfix/cleanup[29190]: 74078120D0C: 
message-id=
Apr 19 06:18:44 mail postfix/cleanup[16471]: D7F3B120D0C: 
message-id=


When I detect those in the logs I add the MAIL FROM address to the 
known-spammer list, which causes the mail to be rejected earlier in 
the SMTP dialogue and seems to stop the retries. Most times I don't 
care whether they're retrying repeatedly, though, it costs more of 
their resources than mine.


Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Tim Düsterhus via mailop]

On 4/19/22 16:57, Laura Atkins via mailop wrote:

We just did 2 tests, one with an email that violated half a dozen best 
practices and one that has a SPFSoftfail (with no DKIM).



I believe you accidentally pasted the same test twice, the headers look 
100% identical to me.


Best regards
Tim Düsterhus
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Michael Peddemors via mailop]

On 2022-04-19 09:17, Scott Mutter via mailop wrote:
It depends on what Google mail server you are sending to.  Some require 
SPF, some don't.


I think you hit the nail on the head.  If processed by normal Gmail 
servers, probably doesn't enforce SPF.. if the domain/ip have had a 
reputation problem before, then probably handled by servers that do have 
SPF requirements.


Just guessing.. Only Gmail peep's can say for sure.


--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Scott Mutter via mailop]

It depends on what Google mail server you are sending to.  Some require
SPF, some don't.  Although, maybe they've since closed that loophole.
Google started requiring SPF records back in December 2021 according to the
logs I reviewed (at least for some of their mail servers).  The mail
servers that don't outright reject messages without SPF may be putting
those messages in the spam folder - I can't really verify that.

I'm a little surprised people are this upset.  Google's using SPF for what
it's actually meant for - and yet people are upset because they are doing
that?  What's the point of adding all of these anti-spam and anti-spoofing
measures into SMTP if you're blackballed for actually using them?

SPF is a great tool to prevent spamming and spoofing - but it depends on
the sender knowing how to set up a proper SPF record (as in knowing exactly
what mail servers their domain name is sending out from).  But very few
people know how to do this (or care to know).

I see Google embracing this as a good thing.  It's telling people that they
need to know what they're setting up and set it up properly.  Otherwise,
don't complain about the spam/phishing/spoofing that continues to go on.


On Tue, Apr 19, 2022 at 10:41 AM Laura Atkins via mailop 
wrote:

> On 19 Apr 2022, at 16:11, Michael Peddemors via mailop 
> wrote:
>
>
> And we also see that they have not yet 'hard enforced', but it looks like
> some trigger on a domain results in requiring SPF for that domain.
>
>
> It wouldn’t surprise me if there were some triggers that made
> authentication be looked at harder. But it is demonstrably incorrect to say
> that Google is requiring certain types of authentication for delivery.
>
> Of course, we don't expect Google to reveal their secrets, but we can
> assume things like new IP(s), new domains, sudden traffic surges, or
> customers clicking on 'this is spam' all might cause the requirement for
> SPF on a certain domain.
>
>
> This was a brand new IP without any rDNS (ie, it’s not intended to send
> mail).
>
> I do expect volume plays into it. But, as I’ve been saying: Google’s
> filtering is nuanced and tries to do the right thing most of the time.
>
> laura
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] Re: FYI - Google/Gmail hard enforcing SPF presence

[Kevin A. McGrail via mailop]

I don't think this is accurate. It seemed to trigger right around the 
start of Russia's invasion of the Ukraine.  I don't think it's 
consistent or has the rhyme/reason you are trying to apply to it in your 
tests.  I would simply say if you have issues with delivery to Google, 
look at your SPF/DKIM/DMARC even if you weren't using them.


On 4/19/2022 12:34 PM, Steve Atkins via mailop wrote:

If you’re being blocked by Google, or “Google is requiring SPF to be accepted” or “I 
had to add DKIM to get mail accepted" then your sending infrastructure, history 
and mailstream reputation is worse than this test setup.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Steve Atkins via mailop]

> On 19 Apr 2022, at 16:11, Michael Peddemors via mailop  
> wrote:
> 
> And we also see that they have not yet 'hard enforced', but it looks like 
> some trigger on a domain results in requiring SPF for that domain.
> 
> Of course, we don't expect Google to reveal their secrets, but we can assume 
> things like new IP(s), new domains, sudden traffic surges, or customers 
> clicking on 'this is spam' all might cause the requirement for SPF on a 
> certain domain.

These were sent from a consumer DSL line with no reverse DNS that’s listed on 
at least one widely used “never accept mail from this IP” list, that has 
virtually no history of IP traffic and zero history of sending email. The mail 
was sent with no SPF, and no DKIM. One of them was sent with no valid return 
path, no valid Message-ID, no valid From: header. Short of my including an 
EICAR test string and an animated gif of me waving a flag saying “DON’T ACCEPT 
THIS MAIL” I can’t think of much else I could do to look less trustworthy.

They both were accepted for delivery just fine.

If you’re being blocked by Google, or “Google is requiring SPF to be accepted” 
or “I had to add DKIM to get mail accepted" then your sending infrastructure, 
history and mailstream reputation is worse than this test setup.

Cheers,
  Steve

> 
> 
> 
> On 2022-04-19 07:57, Laura Atkins via mailop wrote:
>> Short version: google is not hard enforcing SPF presence. Copies of emails 
>> delivered to my google spam folder are attached.
>>> On 19 Apr 2022, at 14:54, Lichtinger, Bernhard via mailop 
>>> mailto:mailop@mailop.org>> wrote:
>>> 
>>> Hi,
>>> 
 Well i have no SPF records. See [doraji.xyz ]. And all 
 incoming emails go
 to Gmail(soyeo...@gmail.com ) by forwarding. 
 The Gmail is my final inbox
 provider. Really there are no troubles, at least, to me...
>>> 
>>> My observation is that Gmail enforces authentication via SPF or DKIM since 
>>> the first days of march 2022.
>>> One of SPF or DKIM is sufficient to get mails delivered to Gmail.
>>> It looks like Gmail imposes a DMARC policy of reject for every sender 
>>> domain ignoring the actual DNS entries for DMARC or their absence.
>> We just did 2 tests, one with an email that violated half a dozen best 
>> practices and one that has a SPFSoftfail (with no DKIM).
>> SPF SoftFail delivered to spam:
>>Delivered-To: wttwla...@gmail.com 
>>Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id
>>i38csp2956940pzk;
>> Tue, 19 Apr 2022 07:44:59 -0700 (PDT)
>>X-Google-Smtp-Source:
>>
>> ABdhPJznmP9P9y29YlGiaLzZTxw0NXW8HUbBKmVBAeegvyAXSFlmXFYoYl/b2Xkgh7yVLnt6UuK7
>>X-Received: by 2002:a5d:6d03:0:b0:20a:7af0:380f with SMTP id
>>e3-20020a5d6d0300b0020a7af0380fmr11823278wrq.148.1650379498973;
>> Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
>>ARC-Seal: i=1; a=rsa-sha256; t=1650379498; cv=none;
>> d=google.com ; s=arc-20160816;
>>
>> b=oAA3r/bEkAyRjN7ZL7C2R9PNSNlehAqTYFpiww5W9ojBBIcPeXwmLRZiMZr3B/Ug5d
>>  
>> BiJezi7mylKI+UO2ywcAG7h1jmTAeizH3j1ghCzukMp2uh3w3oHZ64R+3JAAajACtRcH
>>  
>> lc1BkI/RLdsj7uv7tU3ECElQPX80PC1/hPzxYzc8Si/U761BLX3gVgK+QBeie1HX81JO
>>  
>> HJFtAqVxp/AaVFH4qZuScWJGC23wN5C2Q0pNIytEAc3xk2momvTNrNvYERAqPlYfz32c
>>  
>> 9Li7Yh330SYhCfGwNrCM0tWZJN7/G9YFDPRyWbWh8j71Xqnx3M7XiNrXGPIbcBrvpoNw
>>  INbg==
>>ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
>>d=google.com ; s=arc-20160816;
>> h=message-id:subject:from:to:date;
>> bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=;
>>
>> b=P1PMZlNCzI7TENQ2QO8kaSWDTckbB3jDkrrzxUbjxzgJ/SfGFjHSJpyFttLPHKnatk
>>  
>> pTDj/P5r07tRG7lQ4msWgKZocbyj3y5j6ZNqWRgs189MgDCAb1u533ZJlmRyzWZi2n/3
>>  
>> u50p14IatncLBfPrcxOwMACDBzPRd8P2h72VGcG5V9cRz27WziJmVOxtVEUJk5Hd+c2Z
>>  
>> KoQ+Uzf/lRkGwcKo0MDcQ6qMG3swCdMioHmG4N26/VVOBSNDVbRJZ4J0KR+4TZNO4NlT
>>  
>> gZZKMuWeQvr54C+rtg8ht/OekVrhbksGrKWNoicG78FwORNoUINzJVMAdxhVAWzvWAPq
>>  Vv2g==
>>ARC-Authentication-Results: i=1; mx.google.com ;
>>spf=neutral (google.com : 185.97.236.152
>>is neither permitted nor denied by best guess record for domain of
>>steve@sliver) smtp.mailfrom=steve@sliver
>>Return-Path: 
>>Received: from sliver ([185.97.236.152])
>> by mx.google.com  with ESMTP id
>>p7-20020adfe60700b00203e90194c2si8108892wrm.582.2022.04.19.07.44.58
>> for mailto:wttwla...@gmail.com>>;
>> Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
>>Received-SPF: neutral (google.com :
>>185.97.236.152 is neither permitted nor denied by best guess record
>>for domain of 

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Alexander Bochmann via mailop]

...on 2022-04-19 17:20:04, Andre van Eyssen via mailop wrote:

 > A little testing shows that gmail appears to be rejecting all mail from
 > domains with no SPF record. Having them create the SPF record returned
 > their domains to deliverability in about an hour.

I haven't noticed any recent change, but in general it seemed that 
Gmail was very strict on email delivered via IPv6 for the past couple 
of years, whereas the same sender domains saw no problems when mails 
were sent over IPv4.

Don't have any hard data on this, just casual observation. Though 
at some point I made sure that my systems don't use IPv6 for outgoing 
mail.

Alex.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Rob Nagler via mailop]

On Mon, Apr 18, 2022 at 8:54 PM yuv via mailop  wrote:
> (1) the dissociation of cost and benefits.  economic externalities.
> (2) the dissociation of liability and control.
> (3) competing ownership/property claims.

All excellent points! I would add that reputation management is a hidden
tax (negative externality). This mailing list is part of the tax.

I would rather pay Google a fair price for their service, even though they
are a walled garden. In the days of acoustic couplers, many of us (not me!)
paid for email-as-a-service. Now we pay for reputation-as-a-service or
DIY-reputation.

People ask me why not use AWS? The tax for DIY-hosting is much lower for
one of my (compute-bound) businesses than utility computing.

We all make different economic tradeoffs based on our interests and skills.

Rob
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Luis E . Muñoz via mailop]

On 19 Apr 2022, at 11:02, Russell Clemings via mailop wrote:

> Several users have reported this and I've seen it myself with a couple of
> messages to my gmail from my website. Still troubleshooting, and it's not
> happening consistently, but a missing DKIM in "show original" seems to be
> the common factor.

FWIW, I have observed this on domains that recently changed their mailbox 
provider and have otherwise short sending history or very low volume.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] FYI - Google/Gmail hard enforcing SPF presence

[Luis E . Muñoz via mailop]

On 19 Apr 2022, at 10:54, Kevin A. McGrail via mailop wrote:

> Interesting note that we also saw this a few weeks ago too and had to add 
> DKIM to get mail to work to domains that only had SPF.

Same here.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Laura Atkins via mailop]

On 19 Apr 2022, at 16:11, Michael Peddemors via mailop  
wrote:
> 
> And we also see that they have not yet 'hard enforced', but it looks like 
> some trigger on a domain results in requiring SPF for that domain.

It wouldn’t surprise me if there were some triggers that made authentication be 
looked at harder. But it is demonstrably incorrect to say that Google is 
requiring certain types of authentication for delivery. 

> Of course, we don't expect Google to reveal their secrets, but we can assume 
> things like new IP(s), new domains, sudden traffic surges, or customers 
> clicking on 'this is spam' all might cause the requirement for SPF on a 
> certain domain.

This was a brand new IP without any rDNS (ie, it’s not intended to send mail). 

I do expect volume plays into it. But, as I’ve been saying: Google’s filtering 
is nuanced and tries to do the right thing most of the time. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Michael Peddemors via mailop]

And we also see that they have not yet 'hard enforced', but it looks 
like some trigger on a domain results in requiring SPF for that domain.


Of course, we don't expect Google to reveal their secrets, but we can 
assume things like new IP(s), new domains, sudden traffic surges, or 
customers clicking on 'this is spam' all might cause the requirement for 
SPF on a certain domain.




On 2022-04-19 07:57, Laura Atkins via mailop wrote:
Short version: google is not hard enforcing SPF presence. Copies of 
emails delivered to my google spam folder are attached.


On 19 Apr 2022, at 14:54, Lichtinger, Bernhard via mailop 
mailto:mailop@mailop.org>> wrote:


Hi,

Well i have no SPF records. See [doraji.xyz ]. And 
all incoming emails go
to Gmail(soyeo...@gmail.com ) by 
forwarding. The Gmail is my final inbox

provider. Really there are no troubles, at least, to me...


My observation is that Gmail enforces authentication via SPF or DKIM 
since the first days of march 2022.

One of SPF or DKIM is sufficient to get mails delivered to Gmail.
It looks like Gmail imposes a DMARC policy of reject for every sender 
domain ignoring the actual DNS entries for DMARC or their absence.


We just did 2 tests, one with an email that violated half a dozen best 
practices and one that has a SPFSoftfail (with no DKIM).


SPF SoftFail delivered to spam:

Delivered-To: wttwla...@gmail.com 
Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id
i38csp2956940pzk;
         Tue, 19 Apr 2022 07:44:59 -0700 (PDT)
X-Google-Smtp-Source:
ABdhPJznmP9P9y29YlGiaLzZTxw0NXW8HUbBKmVBAeegvyAXSFlmXFYoYl/b2Xkgh7yVLnt6UuK7
X-Received: by 2002:a5d:6d03:0:b0:20a:7af0:380f with SMTP id
e3-20020a5d6d0300b0020a7af0380fmr11823278wrq.148.1650379498973;
         Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1650379498; cv=none;
         d=google.com ; s=arc-20160816;

b=oAA3r/bEkAyRjN7ZL7C2R9PNSNlehAqTYFpiww5W9ojBBIcPeXwmLRZiMZr3B/Ug5d

  BiJezi7mylKI+UO2ywcAG7h1jmTAeizH3j1ghCzukMp2uh3w3oHZ64R+3JAAajACtRcH

  lc1BkI/RLdsj7uv7tU3ECElQPX80PC1/hPzxYzc8Si/U761BLX3gVgK+QBeie1HX81JO

  HJFtAqVxp/AaVFH4qZuScWJGC23wN5C2Q0pNIytEAc3xk2momvTNrNvYERAqPlYfz32c

  9Li7Yh330SYhCfGwNrCM0tWZJN7/G9YFDPRyWbWh8j71Xqnx3M7XiNrXGPIbcBrvpoNw

          INbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com ; s=arc-20160816;
         h=message-id:subject:from:to:date;
         bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=;

b=P1PMZlNCzI7TENQ2QO8kaSWDTckbB3jDkrrzxUbjxzgJ/SfGFjHSJpyFttLPHKnatk

  pTDj/P5r07tRG7lQ4msWgKZocbyj3y5j6ZNqWRgs189MgDCAb1u533ZJlmRyzWZi2n/3

  u50p14IatncLBfPrcxOwMACDBzPRd8P2h72VGcG5V9cRz27WziJmVOxtVEUJk5Hd+c2Z

  KoQ+Uzf/lRkGwcKo0MDcQ6qMG3swCdMioHmG4N26/VVOBSNDVbRJZ4J0KR+4TZNO4NlT

  gZZKMuWeQvr54C+rtg8ht/OekVrhbksGrKWNoicG78FwORNoUINzJVMAdxhVAWzvWAPq

          Vv2g==
ARC-Authentication-Results: i=1; mx.google.com ;
        spf=neutral (google.com : 185.97.236.152
is neither permitted nor denied by best guess record for domain of
steve@sliver) smtp.mailfrom=steve@sliver
Return-Path: 
Received: from sliver ([185.97.236.152])
         by mx.google.com  with ESMTP id
p7-20020adfe60700b00203e90194c2si8108892wrm.582.2022.04.19.07.44.58
         for mailto:wttwla...@gmail.com>>;
         Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
Received-SPF: neutral (google.com :
185.97.236.152 is neither permitted nor denied by best guess record
for domain of steve@sliver) client-ip=185.97.236.152;
Authentication-Results: mx.google.com ;
        spf=neutral (google.com : 185.97.236.152
is neither permitted nor denied by best guess record for domain of
steve@sliver) smtp.mailfrom=steve@sliver
Date: Tue, 19 Apr 2022 15:44:58 +0100
To: wttwla...@gmail.com 
From: steve@sliver
Subject: test Tue, 19 Apr 2022 15:44:58 +0100
Message-Id: <20220419154458.051019@sliver>
X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/


This is a test mailing


This message probably shouldn’t have been accepted. The number of spec 
and best practice violations is extremely high. But it, too, ended up in 
my spam folder.


Delivered-To: wttwla...@gmail.com 
Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id
i38csp2956940pzk;
         Tue, 19 Apr 2022 07:44:59 -0700 (PDT)
X-Google-Smtp-Source:

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Russell Clemings via mailop]

I've noticed though that if you don't have _both_ SPF and DKIM, you risk
getting routed to the spam folder, and/or getting the scary yellow "Be
careful with this message" warning.

Several users have reported this and I've seen it myself with a couple of
messages to my gmail from my website. Still troubleshooting, and it's not
happening consistently, but a missing DKIM in "show original" seems to be
the common factor.



On Tue, Apr 19, 2022 at 7:08 AM Lichtinger, Bernhard via mailop <
mailop@mailop.org> wrote:

> Hi,
>
> > Well i have no SPF records. See [doraji.xyz]. And all incoming emails go
> > to Gmail(soyeo...@gmail.com) by forwarding. The Gmail is my final inbox
> > provider. Really there are no troubles, at least, to me...
>
> My observation is that Gmail enforces authentication via SPF or DKIM since
> the first days of march 2022.
> One of SPF or DKIM is sufficient to get mails delivered to Gmail.
> It looks like Gmail imposes a DMARC policy of reject for every sender
> domain ignoring the actual DNS entries for DMARC or their absence.
>
>
> Regards,
> Bernhard
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>


-- 
===
Russell Clemings

===
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] FYI - Google/Gmail hard enforcing SPF presence

[Kevin A. McGrail via mailop]

Interesting note that we also saw this a few weeks ago too and had to 
add DKIM to get mail to work to domains that only had SPF.


On 4/19/2022 3:20 AM, Andre van Eyssen via mailop wrote:
A little testing shows that gmail appears to be rejecting all mail 
from domains with no SPF record. Having them create the SPF record 
returned their domains to deliverability in about an hour.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Laura Atkins via mailop]

Short version: google is not hard enforcing SPF presence. Copies of emails 
delivered to my google spam folder are attached. 

> On 19 Apr 2022, at 14:54, Lichtinger, Bernhard via mailop  
> wrote:
> 
> Hi,
> 
>> Well i have no SPF records. See [doraji.xyz]. And all incoming emails go
>> to Gmail(soyeo...@gmail.com) by forwarding. The Gmail is my final inbox
>> provider. Really there are no troubles, at least, to me...
> 
> My observation is that Gmail enforces authentication via SPF or DKIM since 
> the first days of march 2022.
> One of SPF or DKIM is sufficient to get mails delivered to Gmail. 
> It looks like Gmail imposes a DMARC policy of reject for every sender domain 
> ignoring the actual DNS entries for DMARC or their absence.

We just did 2 tests, one with an email that violated half a dozen best 
practices and one that has a SPFSoftfail (with no DKIM).

SPF SoftFail delivered to spam: 

Delivered-To: wttwla...@gmail.com
Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id i38csp2956940pzk;
Tue, 19 Apr 2022 07:44:59 -0700 (PDT)
X-Google-Smtp-Source: 
ABdhPJznmP9P9y29YlGiaLzZTxw0NXW8HUbBKmVBAeegvyAXSFlmXFYoYl/b2Xkgh7yVLnt6UuK7
X-Received: by 2002:a5d:6d03:0:b0:20a:7af0:380f with SMTP id 
e3-20020a5d6d0300b0020a7af0380fmr11823278wrq.148.1650379498973;
Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1650379498; cv=none;
d=google.com; s=arc-20160816;
b=oAA3r/bEkAyRjN7ZL7C2R9PNSNlehAqTYFpiww5W9ojBBIcPeXwmLRZiMZr3B/Ug5d
 BiJezi7mylKI+UO2ywcAG7h1jmTAeizH3j1ghCzukMp2uh3w3oHZ64R+3JAAajACtRcH
 lc1BkI/RLdsj7uv7tU3ECElQPX80PC1/hPzxYzc8Si/U761BLX3gVgK+QBeie1HX81JO
 HJFtAqVxp/AaVFH4qZuScWJGC23wN5C2Q0pNIytEAc3xk2momvTNrNvYERAqPlYfz32c
 9Li7Yh330SYhCfGwNrCM0tWZJN7/G9YFDPRyWbWh8j71Xqnx3M7XiNrXGPIbcBrvpoNw
 INbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
h=message-id:subject:from:to:date;
bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=;
b=P1PMZlNCzI7TENQ2QO8kaSWDTckbB3jDkrrzxUbjxzgJ/SfGFjHSJpyFttLPHKnatk
 pTDj/P5r07tRG7lQ4msWgKZocbyj3y5j6ZNqWRgs189MgDCAb1u533ZJlmRyzWZi2n/3
 u50p14IatncLBfPrcxOwMACDBzPRd8P2h72VGcG5V9cRz27WziJmVOxtVEUJk5Hd+c2Z
 KoQ+Uzf/lRkGwcKo0MDcQ6qMG3swCdMioHmG4N26/VVOBSNDVbRJZ4J0KR+4TZNO4NlT
 gZZKMuWeQvr54C+rtg8ht/OekVrhbksGrKWNoicG78FwORNoUINzJVMAdxhVAWzvWAPq
 Vv2g==
ARC-Authentication-Results: i=1; mx.google.com;
   spf=neutral (google.com: 185.97.236.152 is neither permitted nor denied 
by best guess record for domain of steve@sliver) smtp.mailfrom=steve@sliver
Return-Path: 
Received: from sliver ([185.97.236.152])
by mx.google.com with ESMTP id 
p7-20020adfe60700b00203e90194c2si8108892wrm.582.2022.04.19.07.44.58
for ;
Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
Received-SPF: neutral (google.com: 185.97.236.152 is neither permitted nor 
denied by best guess record for domain of steve@sliver) 
client-ip=185.97.236.152;
Authentication-Results: mx.google.com;
   spf=neutral (google.com: 185.97.236.152 is neither permitted nor denied 
by best guess record for domain of steve@sliver) smtp.mailfrom=steve@sliver
Date: Tue, 19 Apr 2022 15:44:58 +0100
To: wttwla...@gmail.com
From: steve@sliver
Subject: test Tue, 19 Apr 2022 15:44:58 +0100
Message-Id: <20220419154458.051019@sliver>
X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/

This is a test mailing

This message probably shouldn’t have been accepted. The number of spec and best 
practice violations is extremely high. But it, too, ended up in my spam folder. 

Delivered-To: wttwla...@gmail.com
Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id i38csp2956940pzk;
Tue, 19 Apr 2022 07:44:59 -0700 (PDT)
X-Google-Smtp-Source: 
ABdhPJznmP9P9y29YlGiaLzZTxw0NXW8HUbBKmVBAeegvyAXSFlmXFYoYl/b2Xkgh7yVLnt6UuK7
X-Received: by 2002:a5d:6d03:0:b0:20a:7af0:380f with SMTP id 
e3-20020a5d6d0300b0020a7af0380fmr11823278wrq.148.1650379498973;
Tue, 19 Apr 2022 07:44:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1650379498; cv=none;
d=google.com; s=arc-20160816;
b=oAA3r/bEkAyRjN7ZL7C2R9PNSNlehAqTYFpiww5W9ojBBIcPeXwmLRZiMZr3B/Ug5d
 BiJezi7mylKI+UO2ywcAG7h1jmTAeizH3j1ghCzukMp2uh3w3oHZ64R+3JAAajACtRcH
 lc1BkI/RLdsj7uv7tU3ECElQPX80PC1/hPzxYzc8Si/U761BLX3gVgK+QBeie1HX81JO
 HJFtAqVxp/AaVFH4qZuScWJGC23wN5C2Q0pNIytEAc3xk2momvTNrNvYERAqPlYfz32c
 9Li7Yh330SYhCfGwNrCM0tWZJN7/G9YFDPRyWbWh8j71Xqnx3M7XiNrXGPIbcBrvpoNw
 INbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
h=message-id:subject:from:to:date;
bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=;
b=P1PMZlNCzI7TENQ2QO8kaSWDTckbB3jDkrrzxUbjxzgJ/SfGFjHSJpyFttLPHKnatk
 pTDj/P5r07tRG7lQ4msWgKZocbyj3y5j6ZNqWRgs189MgDCAb1u533ZJlmRyzWZi2n/3
 u50p14IatncLBfPrcxOwMACDBzPRd8P2h72VGcG5V9cRz27WziJmVOxtVEUJk5Hd+c2Z
 

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Slavko via mailop]

Dňa 19. apríla 2022 13:54:30 UTC používateľ "Lichtinger, Bernhard via mailop" 
 napísal:

>It looks like Gmail imposes a DMARC policy of reject for every sender domain 
>ignoring the actual DNS entries for DMARC or their absence.

In other words, gmail know better what is better for me (my domains/mails)  as 
I?

Interesting... Gmail can shutdown their MTAs, this will 100 % solve their SPAM 
problem
-- no one gmail user will receive SPAM anymore, and will solve the SPAM problem
for others too (at least partially).

BTW, if someone is trying to solve your problems, not alvays want to help you...

Slavko
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Lichtinger, Bernhard via mailop]

Hi,

> Well i have no SPF records. See [doraji.xyz]. And all incoming emails go
> to Gmail(soyeo...@gmail.com) by forwarding. The Gmail is my final inbox
> provider. Really there are no troubles, at least, to me...

My observation is that Gmail enforces authentication via SPF or DKIM since the 
first days of march 2022.
One of SPF or DKIM is sufficient to get mails delivered to Gmail. 
It looks like Gmail imposes a DMARC policy of reject for every sender domain 
ignoring the actual DNS entries for DMARC or their absence.


Regards,
Bernhard




smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] MTA-STS Key-Value Delimiter

[Brotman, Alex via mailop]

I checked our logs, and I don’t see that we've attempted delivery to the domain 
below so I can't see what we're saving off/reporting.  When I receive TLSRPT 
files from Gmail, I'm getting that string as:

"policy-string":["version: STSv1","mode: enforce ","mx: mx2c1.comcast.net","mx: 
mx2h1.comcast.net","mx: mx1a1.comcast.net","mx: mx1h1.comcast.net","mx: 
mx1c1.comcast.net","mx: mx2a1.comcast.net","max_age: 2592000"]

Your policy file appears okay to me (I see a trailing CRLF after the max_age I 
believe).  If you'd like to provide an email address, I can attempt a test 
message to generate a report.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: mailop  On Behalf Of Tobias Fiebig via
> mailop
> Sent: Tuesday, April 19, 2022 6:43 AM
> To: mailop@mailop.org
> Subject: [EXTERNAL] [mailop] MTA-STS Key-Value Delimiter
>
> Heho,
> I recently deployed MTA-STS, but am somewhat lost with the kv delimiters in
> the policy file:
>
> RFC8461 calls for CRLF delimited values; Errata 6253 notes that this _should_
> have been CRLF or LF. I opted for the former, assuming that it is more likely
> people didn't read the eratta and only delimit on CRLF, while those reading
> the eratta most likely would to both:
>
> From the report:
> "policy-string":["version: STSv1\r","mode: enforce\r","mx: mail.aperture-
> labs.org\r","mx: mail2.aperture-labs.org\r","max_age: 86400\r"]
>
> In the MTA-STS reports I am getting (from google only so far) now, I do see
> that they are delmiting on LF only, pulling the CR into the values, at least 
> in
> the reported policy.
>
> I am now wondering if this might cause any issues?
>
> With best regards,
> Tobias
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!CQl
> 3mcHX2A!Q42nbizjAB0ysCfjyVSLHJ8Y-W2PaWINLljUATGyjhoWuOaC8pjv-
> 8nHnQdFOPIPm75e$
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Byung-Hee HWANG via mailop]

Dear Andre,

Andre van Eyssen via mailop  writes:

> (... thanks ...)
> A little testing shows that gmail appears to be rejecting all mail
> from domains with no SPF record. Having them create the SPF record
> returned their domains to deliverability in about an hour.

Well i have no SPF records. See [doraji.xyz]. And all incoming emails go
to Gmail(soyeo...@gmail.com) by forwarding. The Gmail is my final inbox
provider. Really there are no troubles, at least, to me...

Thanks!

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] MTA-STS Key-Value Delimiter

[Tobias Fiebig via mailop]

Heho,
I recently deployed MTA-STS, but am somewhat lost with the kv delimiters in the 
policy file:

RFC8461 calls for CRLF delimited values; Errata 6253 notes that this _should_ 
have been CRLF or LF. I opted for the former, assuming that it is more likely 
people didn't read the eratta and only delimit on CRLF, while those reading the 
eratta most likely would to both:

From the report:
"policy-string":["version: STSv1\r","mode: enforce\r","mx: 
mail.aperture-labs.org\r","mx: mail2.aperture-labs.org\r","max_age: 86400\r"]

In the MTA-STS reports I am getting (from google only so far) now, I do see 
that they are delmiting on LF only, pulling the CR into the values, at least in 
the reported policy.

I am now wondering if this might cause any issues?

With best regards,
Tobias



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] FYI - Google/Gmail hard enforcing SPF presence

[Andre van Eyssen via mailop]

Hi all,

A week or so ago I was dealing with some domains that were nearly 100% 
bouncing on delivery to gmail. It turns out that the domain owners had 
made registrar/DNS hosting changes and while they managed to create the MX 
records correctly, they left out the SPF.


A little testing shows that gmail appears to be rejecting all mail from 
domains with no SPF record. Having them create the SPF record returned 
their domains to deliverability in about an hour.


Just a heads-up!

Andre.




--
Andre van Eyssen.  Phone: +61 417 211 788
mail: an...@purplecow.org  http://andre.purplecow.org
About & Contact:  http://www.purplecow.org/andre.html
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Hans-Martin Mosner via mailop]

Am 18.04.22 um 21:02 schrieb Bill Cole via mailop:

On 2022-04-18 at 13:32:07 UTC-0400 (Mon, 18 Apr 2022 12:32:07 -0500)
Larry M. Smith via mailop 
is rumored to have said:


...
I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, or 
Microsoft do NOT re-queue messages after receiving a 5xx response -- Qmail does.


Did you mean "GMail?"

FWIW, I've not seen GMail (or Qmail) do that. Do you know how to reproduce it?

I have a current sample where GMail did this. They apparently do it for 5.7.1 responses to DATA only, and not always, 
but I don't have complete statistics for this.


Here are the log entries for the recent run (which were rejected after DATA due to a known-spammer body pattern, which 
is one possible way to keep the ever-changing GMail 4-1-9ers somewhat in check.) Note that identical message ID provies 
that this isn't the spammer repeatedly trying to get his/her fraud message across, but Google trying to force the spam 
down our throat :-)


Apr 18 19:43:34 mail postfix/cleanup[23243]: 7D1D4120D85: 
message-id=
Apr 18 19:50:22 mail postfix/cleanup[24996]: 7C34B120D72: 
message-id=
Apr 18 20:13:48 mail postfix/cleanup[27908]: 8189A120D84: 
message-id=
Apr 18 20:40:41 mail postfix/cleanup[459]: 059EB120D0C: 
message-id=
Apr 18 21:25:48 mail postfix/cleanup[15781]: DAAD7120D74: 
message-id=
Apr 18 22:16:56 mail postfix/cleanup[28107]: 43595120D0C: 
message-id=
Apr 18 23:43:07 mail postfix/cleanup[14675]: 0F230120D30: 
message-id=
Apr 19 01:13:13 mail postfix/cleanup[25151]: 50B47120D0C: 
message-id=
Apr 19 02:44:45 mail postfix/cleanup[9739]: 23C56120D0C: 
message-id=
Apr 19 04:30:16 mail postfix/cleanup[29190]: 74078120D0C: 
message-id=
Apr 19 06:18:44 mail postfix/cleanup[16471]: D7F3B120D0C: 
message-id=


When I detect those in the logs I add the MAIL FROM address to the known-spammer list, which causes the mail to be 
rejected earlier in the SMTP dialogue and seems to stop the retries. Most times I don't care whether they're retrying 
repeatedly, though, it costs more of their resources than mine.


Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop