Re: [mailop] [E] $GOOG

[Rob McEwen via mailop]

On 4/20/2022 11:41 PM, Larry M. Smith via mailop wrote:
I'd suggest anything that shows gmailapi.google.com in the header be 
rejected -- at least until Google can get a handle on the abuse



Excellent information - somehow, this slipped under my radar. So I've 
just done some cursory analysis of this in the past 1 hour. This is 
definitely worth exploring - however - those with large mail systems 
and/or who are adverse to having false positives - just know that this 
will hit on a significant amount of false positives. For example, what I 
found  is that some CRMs and some accounting systems - use this Google 
API for things like sending invoices to clients and for other legit 
transactional messages, and that sometimes happens for both gsuite 
business addresses (using their own domain) AND gmail addresses, too. 
Also, even if it had zero false positives (it doesn't come close to 
that) - even then - of all gmail spams, the total gmail spams that this 
hits is about 1/5th or 1/4th of all gmail spams, so this far from a 
comprehensive solution to the gmail spam issue, not even considering the 
false positives. Too many other gmail-sent spams don't have that header.


However, this still might be worth adding a point or two to the spam 
score and/or amplifying other existing scoring? And that will work even 
better if combined with using email and domain name WLs that would then 
further minimize potential false positives (so not apply this scoring to 
those messages).


So this is still very helpful info! Thanks!

--
Rob McEwen, invaluement

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

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

yuv via mailop wrote on 2022-04-18 19:54:

On Mon, 2022-04-18 at 06:16 +0200, Paul Vixie via mailop wrote:

...


... Earlier in this
interesting thread you qualified Gmail as "late stage surveillance
capitalism."  Has it occured to you that reputation services, whether
distributed or other, are early stage surveillace capitalism?


no.


I am not
familiar with the lawsuits, but the general solution to all reputation
services, whether IP-reputation, consumer credit, or any other business
that collects information about other subjects (the building block of
surveillance capitalism!) is consent:  if the subject does not consent,
do not collect/report.  No reporting, no cause for legal action.
Provide reputation certificates for subjects that opt into the service
and let recipients decide how to deal with the absence of such
reputation ceritificate(s).


your unfamiliarity extends demonstrably beyond the lawsuits. if you 
choose to do some research and ask some informed questions, i'd love to 
hear them and try to engage further.


--
P Vixie

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

Re: [mailop] Is there any cloudflare staff here?

[Alexander Huynh via mailop]

Reaching out off-list.
-- 
Alexander Huynh
R, Cloudflare
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Larry M. Smith via mailop]

On 4/19/2022, Hans-Martin Mosner via mailop wrote:
(snip)>
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.




There is a group of spammers that have been on Gmail for months and 
using something that shows in the header records as gmailapi.google.com. 
 Given that it appears that the spammers have a near endless supply of 
gmail addresses to send from, I don't know how effective that strategy 
might be.


API documentation for defining aliases on the fly;
https://developers.google.com/gmail/api/guides/alias_and_signature_settings

.. I'd suggest anything that shows gmailapi.google.com in the header be 
rejected -- at least until Google can get a handle on the abuse.


E.g.;
Received: from .* named unknown by gmailapi.google.com with HTTPREST;
 Mon, 18 Apr 2022 16:53:54 -0700


--
SgtChains

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

Re: [mailop] [E] $GOOG

[Larry M. Smith via mailop]

On 4/18/2022, Bill Cole via mailop wrote:
(snip)

Did you mean "GMail?"



Yes, you are correct -- Gmail.  Sorry about that.  Finger memory, or 
something.


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

Re: [mailop] DKIM by the third party

[Rob McEwen via mailop]

On 4/20/2022 10:04 PM, Henrik S via mailop wrote:
My mail is sent by the third party smtp server, and the dkim signature 
is made for the third party domain (for this case, it's pobox.com).
does this DKIM have helps to the authorization of my outgoing messages? 



I'm curious about others' opinions - but - coincidentally:

(1) in a recent project to do a years-overdue rewrite of much of the 
engine behind invaluement - we're looking at this practice very 
negatively especially if/when the SMTP provider sends a mix of ham/spam 
- and so in MANY cases - and so we don't consider the DKIM to be all 
that particularly valid if/when NONE of the DKIM headers align with the 
Mail Header FROM domain


(2) also - coincidentally - another huge consideration is this scenario:

Suppose important/valid transactional messages are sent via 3rd party 
SMTP/ESP - the Return Path (SMTP envelope) FROM domain is that 
provider's domain - therefore - the SPF record technically just 
references that 3rd party SMTP/ESP. And suppose in this example that the 
ONLY DKIM record in the header - does what you described (pointing to 
3rd party) and therefore has a "d=" pointing to that SMTP/ESP's generic 
domain. So in that scenario - if the SMTP-provider/ESP doesn't have good 
security and frequently allows criminals onto their system (which is NOT 
unusual) - what's preventing some criminal from doing the SAME thing, 
but then forging in a legit institution's domain into the FROM address 
and sending a phish - where that financial institution ALSO uses this 
same 3rd party SMTP or ESP? In that case, the phish will technically 
pass both DKIM and SPF - although it still won't pass the stricter 
standard of the mail header domain having alignment with the DKIM record 
- THUS the reason for our stance described in (1) above! That is a HUGE 
potential security loophole that can't be underestimated or ignored!


(3) I recently came across an example from AmazonSES that was SIMILAR to 
this - but not technically bad - in this case, the message had 2 DKIM 
records, and one of those DKIM records in the mail header was for the 
senders's mail-header FROM domain - which used that sender's main domain 
name, thus solving this problem. (the other DKIM was for amazonses). It 
was from an entity where great damage could be done if a criminal was 
able to setup an account with AmazonSES and then do what I described 
above in (2). So I sent a PM to Paul Vixie asking him if, in that 
scenario, Amazon SES enforces the use of a DKIM for the senders' own 
mail-header domain - and if AmazonSES actively prevents criminals from 
getting onto their system and doing what I describe in (2) above. I just 
sent this to Paul Vixie only a couple of days ago - he might not have 
even seen it yet? - where I asked Paul if AmazonSES already enforces a 
solution? (since they seem to be VERY close to having that issue 
described above - but maybe they've already solved this?) So maybe 
AmazonSES is enforcing this Mail Header FROM alignment - or is otherwise 
preventing criminals from using this loophole that attempts to 
impersonate their other customers? I'm guessing that they do, but I 
wanted to be sure. But this is a possible horrific loophole might apply 
to many SMTP-providers and ESPs!


(4) For all these reasons, I definitely recommend making sure there is a 
DKIM record that aligns with the mail-header FROM address! ...and then 
ALSO using a mail-header FROM address that uses a domain that properly 
conveys that sending organizations' identity and reputation, and NOT 
using a "throw away" domain (as many spammers, and some legit senders, 
do to try to protect their main domain from getting listed on an 
anti-spam list - but more legit senders who don't sent spam - don't tend 
to NEED to use such questionable tactics)


--
Rob McEwen, invaluement

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

[mailop] Is there any cloudflare staff here?

[Henrik S via mailop]

I found a possible bug for their email routing.

I have two mailboxes on this domain whose email is handled by cloudflare 
email route.


userA -> catchall forwarded -> gmail
userB -> specific forwarded -> yahoo

both userA and userB have subscribed to the debian mailing lists.

But, the messages sent from debian lists, only reached into gmail, the 
yahoo mailbox never received this kind of message, even the list message 
is sent from userB.


So I doubt:

cloudflare found the recipient address in message header has no userB 
included (the recipient in a list mail is the list address), it 
forwarded the messages to the catchall address (userA).


So this is the bug. maybe need your verification.

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

Re: [mailop] DKIM by the third party

[Byung-Hee HWANG via mailop]

Henrik S via mailop  writes:

> (... thanks ...)
> does this DKIM have helps to the authorization of my outgoing messages?

The answer is "case by case".

And i'm doing that [^^^] for forwarding (to Gmail).

Sincerely, Linux fan Byung-Hee

[^^^] test screenshot with forwarding to gmail:


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

[mailop] DKIM by the third party

[Henrik S via mailop]

Hello

My mail is sent by the third party smtp server, and the dkim signature 
is made for the third party domain (for this case, it's pobox.com).


does this DKIM have helps to the authorization of my outgoing messages?

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

Re: [mailop] Odd delay at Gmail ?

[Luis E . Muñoz via mailop]

On 20 Apr 2022, at 13:06, Bill Cole via mailop wrote:

> When I looked at this phenomenon I didn't see any clumping of delay times, 
> but I only had a few dozen with delays 10m-10h so they were pretty sparsely 
> scattered.

Matches me—few and apart—observations.

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

Re: [mailop] Odd delay at Gmail ?

[Luis E . Muñoz via mailop]

On 20 Apr 2022, at 12:35, Cyril - ImprovMX via mailop wrote:

> That idea also crossed my mind, that it would only be displayed when the
> actual time is > than the Date in the email.
> Unfortunately, that's something I cannot tell, I don't know and since it is
> occurring rarely, it's hard to ask the user to "try again".

Depending on how curious you are, you can always take a message, edit on disk 
to have a timestamp in the future, and them move to Gmail storage via IMAP :-)

-lem
___
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)

[John Levine via mailop]

It appears that Atro Tossavainen via mailop  said:
>> 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.

Same here.  Whatever they do to prevent crooked customers from signing up,
or keeping legit customers from being compromised doesn't work very well.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Bill Cole via mailop]

On 2022-04-20 at 12:08:09 UTC-0400 (Wed, 20 Apr 2022 17:08:09 +0100)
Laura Atkins via mailop 
is rumored to have said:

> It seems weird to me that Google would sit on an email for exactly 8 hours

Pedantic note: the times cited were actually 7:54:45 apart, so it's not some 
oddly even amount of time.

When I looked at this phenomenon I didn't see any clumping of delay times, but 
I only had a few dozen with delays 10m-10h so they were pretty sparsely 
scattered.

-- 
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] Odd delay at Gmail ?

[Cyril - ImprovMX via mailop]

That idea also crossed my mind, that it would only be displayed when the
actual time is > than the Date in the email.
Unfortunately, that's something I cannot tell, I don't know and since it is
occurring rarely, it's hard to ask the user to "try again".

Le mer. 20 avr. 2022 à 18:11, Laura Atkins via mailop  a
écrit :

>
>
> On 20 Apr 2022, at 16:44, Cyril - ImprovMX via mailop 
> wrote:
>
> Thank you all.
>
> About Laura's question, I can confirm that on our end, we successfully
> forwarded the message with a 2XX response from Google within a few seconds.
> Our timestamp show that this user should have received the email 8 hours
> before he really received it.
>
>
> How was he accessing the mail? Was he using an IMAP client or one of the
> Google controlled MUAs?
>
> Like, I’m wondering if this was just a display issue (say: Google won’t
> display mail until the actual timestamp) or if Google really held onto the
> mail somewhere in a spool until the timestamp was accurate. It seems weird
> to me that Google would sit on an email for exactly 8 hours and then
> deliver it to him. But it seems not-unreasonable to me that Google would
> have their client set to not display email until after it was delivered
> (and because of the timestamp issue it wasn’t ‘delivered’ for 8 hours.
>
> But an IMAP client that isn’t under the control of Google will display the
> message if it’s in the inbox, no matter if it was delivered yet or not.
>
> 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] Odd delay at Gmail ?

[Laura Atkins via mailop]

> On 20 Apr 2022, at 16:44, Cyril - ImprovMX via mailop  
> wrote:
> 
> Thank you all.
> 
> About Laura's question, I can confirm that on our end, we successfully 
> forwarded the message with a 2XX response from Google within a few seconds. 
> Our timestamp show that this user should have received the email 8 hours 
> before he really received it.

How was he accessing the mail? Was he using an IMAP client or one of the Google 
controlled MUAs? 

Like, I’m wondering if this was just a display issue (say: Google won’t display 
mail until the actual timestamp) or if Google really held onto the mail 
somewhere in a spool until the timestamp was accurate. It seems weird to me 
that Google would sit on an email for exactly 8 hours and then deliver it to 
him. But it seems not-unreasonable to me that Google would have their client 
set to not display email until after it was delivered (and because of the 
timestamp issue it wasn’t ‘delivered’ for 8 hours. 

But an IMAP client that isn’t under the control of Google will display the 
message if it’s in the inbox, no matter if it was delivered yet or not. 

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] Odd delay at Gmail ?

[Cyril - ImprovMX via mailop]

Thank you all.

About Laura's question, I can confirm that on our end, we successfully
forwarded the message with a 2XX response from Google within a few seconds.
Our timestamp show that this user should have received the email 8 hours
before he really received it.

@Alexander: Your suggestion is very interesting! We recently started
implementing MTA-STS so it's highly possible that we messed something up in
that regard. I'll take a close look tomorrow about it. If I find anything,
I'll keep this thread updated.

If any of you have any suggestions, I'm all ears!

Thank you for your help!!

Le mer. 20 avr. 2022 à 15:39, Alexander Huynh via mailop 
a écrit :

> On 2022-04-20 12:51:47 +0200, Cyril - ImprovMX wrote:
> > What happened here ?
>
> Anecdotally, I recently switched MX servers and found that my emails
> from Google were also delayed for about 8 hours. The next day when I
> received my MTA-STS reports, I found 53 failures as reported by Google,
> since my then MTA-STS policy did not include the new MX server. While I
> can't say your issue is due to MTA-STS cache invalidation, I would
> suggest checking the various nuts and bolts both internally, and using
> external validators.
>
> Hope this helps,
> --
> Alex
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Alexander Huynh via mailop]

On 2022-04-20 12:51:47 +0200, Cyril - ImprovMX wrote:
> What happened here ?

Anecdotally, I recently switched MX servers and found that my emails
from Google were also delayed for about 8 hours. The next day when I
received my MTA-STS reports, I found 53 failures as reported by Google,
since my then MTA-STS policy did not include the new MX server. While I
can't say your issue is due to MTA-STS cache invalidation, I would
suggest checking the various nuts and bolts both internally, and using
external validators.

Hope this helps,
-- 
Alex
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Bill Cole via mailop]

On 2022-04-20 at 06:51:47 UTC-0400 (Wed, 20 Apr 2022 12:51:47 +0200)
Cyril - ImprovMX via mailop 
is rumored to have said:


What happened here ?


Gmail happened. Only Google (maybe) knows what this phenomenon is. Maybe 
Brandon Long will speak up here about it, maybe not.


Our logs clearly show that we forwarded the email in under 2 seconds 
and we didn't mess with the dates (or anything, for that matter).


Does anyone here experience this before?


Yes. It was completely non-reproducible as far as I could tell when I 
tried to analyze it in 2019. Delays of over 10 minutes hit <0.1% of 
messages in the flow I was working with.



Do you have any explanations about what happened?


AFAICT, it's random breakage inside Google. My theory is that they have 
a failure mode in queueing between external MX nodes and the next 
internal hop that can cause very long queues that take hours to clear. 
Pure guess. Secondary theory: it's by design: some messy cousin of 
greylisting.


I'd love to reach out to Gmail to ask them about this, but, well, it's 
Gmail.


Right. Occasionally worth almost what you pay for it, as long as you can 
ignore the random breakage, because you don't have the option of getting 
anything done about it.



--
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] [EXTERNAL] Re: Outbound DANE Enforced on Exchange/Microsoft 365

[Brotman, Alex via mailop]

I think this is the blog post: 
https://techcommunity.microsoft.com/t5/exchange-team-blog/releasing-outbound-smtp-dane-with-dnssec/ba-p/3100920

We support both MTA-STS/DANE inbound/outbound, as well as supporting both via 
generated TLSRPT reports.  While it seems that Gmail is the current example of 
MTA-STS-only, that could always change.  We still have tons of providers that 
support neither, and I'd take either as a step above Opportunistic TLS.

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

> -Original Message-
> From: mailop  On Behalf Of Sidsel Jensen via
> mailop
> Sent: Wednesday, April 20, 2022 3:58 AM
> To: mailop 
> Subject: [EXTERNAL] Re: [mailop] Outbound DANE Enforced on
> Exchange/Microsoft 365
>
> Hi Matt
>
> Yeah - they’ve been doing it for quite a while - the Dutch SIDNLabs actually 
> have
> some pretty nice graphs showing the number of queries for TLSA records
> https://stats.sidnlabs.nl/en/mail.html#tlsa#tlsa
>
> I believe they are also working on a blog-entry about the progress - maybe
> someone from MS can provide more insight :-)
>
> Kind Regards,
>   Sidsel
>
> > On 20 Apr 2022, at 02.03, Matt Corallo via mailop 
> wrote:
> >
> > This happened a little while ago, but still maybe worth posting here. 
> > According
> to [1] and my own TLS-RPT reports from Microsoft, they're actively enforcing
> DANE on outbound mails now!
> >
> > It seems sans one major holdout its finally time to ditch MTA-STS entirely 
> > and
> not bother with the rube-goldberg machine that it is, assuming you get DNSSEC
> set up properly on your MX domain(s). Doubly so given there's not even good
> open-source software to enforce it, so DANE gives good coverage outside of
> the few big players, vs MTA-STS is only useful with one major sender...
> >
> > Matt
> >
> > [1]
> > https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=
> > erms=dnssec ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop

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

[mailop] Odd delay at Gmail ?

[Cyril - ImprovMX via mailop]

Hi everyone !

I'm reaching out in the hope to find someone in the same situation, and
that I can receive some input on why this happened.

We forward a lot of emails including to Gmail, and a user reached out to us
because their email arrived in their inbox with a delay of 8 hours!

That user was able to send us the .eml, so I was able to peak at the
headers. What I noticed is that the Date present in the email was in UTC
all the way up to us, but when it left our server and landed at Gmail, it
changed, but ... oddly.

The "Date" header was "Thu, 14 Apr 2022 18:29:43 +" and during the
processing in the sender, and in our servers, it remained the same with a
few seconds changing, but that's all.

We forwarded it to "gmail-smtp-in.l.google.com", and the next date present
(in the "Received" header) became "Thu, 14 Apr 2022 19:24:28 -0700 (PDT)"

I don't mind the timezone changing, but the hour only changed for one hour,
while the timezone changed by an offset of 7 hours! The two changes
resulted in a difference of 8 hours, which is exactly when the user saw his
email in his inbox.

What happened here ?

Our logs clearly show that we forwarded the email in under 2 seconds and we
didn't mess with the dates (or anything, for that matter).

Does anyone here experience this before? Do you have any explanations about
what happened?

I'd love to reach out to Gmail to ask them about this, but, well, it's
Gmail.

Thank you for your help!

Best,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Tobias Fiebig via mailop]

Heho,
Good to hear it is only cosmetic. :-)

> I do think it's reasonable to assume CRLF is the safer value. :)
Well, difficult. I'd say that the initial phrasing of the RFC might have cause 
some confusion. But one would have to gauge a lot more implementations to know 
that... 樂 Might be a worthwhile measurement study.

With best regards,
Tobias 

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

Re: [mailop] Outbound DANE Enforced on Exchange/Microsoft 365

[Sidsel Jensen via mailop]

Hi Matt

Yeah - they’ve been doing it for quite a while - the Dutch SIDNLabs actually 
have some pretty nice graphs showing the number of queries for TLSA records
https://stats.sidnlabs.nl/en/mail.html#tlsa#tlsa

I believe they are also working on a blog-entry about the progress - maybe 
someone from MS can provide more insight :-)

Kind Regards,
  Sidsel

> On 20 Apr 2022, at 02.03, Matt Corallo via mailop  wrote:
> 
> This happened a little while ago, but still maybe worth posting here. 
> According to [1] and my own TLS-RPT reports from Microsoft, they're actively 
> enforcing DANE on outbound mails now!
> 
> It seems sans one major holdout its finally time to ditch MTA-STS entirely 
> and not bother with the rube-goldberg machine that it is, assuming you get 
> DNSSEC set up properly on your MX domain(s). Doubly so given there's not even 
> good open-source software to enforce it, so DANE gives good coverage outside 
> of the few big players, vs MTA-STS is only useful with one major sender...
> 
> Matt
> 
> [1] 
> https://www.microsoft.com/en-us/microsoft-365/roadmap?filters==dnssec
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop