[mailop] GSuites looking too closely at first-hop Received: headers?

[Philip Paeps]

I'm at a conference this week, sending email from very untrustworthy IP 
space.  Of course I'm relaying through my usual servers.


Sending mail to a GSuites mailing list (or do they call them "groups"?) 
gets 250 accepted but does not actually arrive on the list.  I don't get 
a copy (I'm subscribed to the list) and other subscribers confirm out of 
band that they don't see my email either (they looked in their spam 
folders too).


I did a couple of experiments.

A message with the first Received: header as follows does not arrive on 
a GSuites-hosted mailing list (despite being 250 accepted):


Received: from twoflower.trouble.is 
(254.158.dhcp.conference.apricot.net [220.247.158.254])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 
bits))

(Client did not present a certificate)
(Authenticated sender: philip)
by rincewind.trouble.is (Postfix) with ESMTPSA id 
3zr7nV5QjfzttZ

for ; Tue, 27 Feb 2018 06:19:10 + (UTC)

An identical message with the first Received like this does arrive:

Received: from twoflower.trouble.is (localhost [127.0.0.1])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 
bits))

(Client did not present a certificate)
(Authenticated sender: philip)
by rincewind.trouble.is (Postfix) with ESMTPSA id 
3zr7xw1W8xztth

for ; Tue, 27 Feb 2018 06:26:28 + (UTC)

The intermediate relays (between my laptop - twoflower.trouble.is) and 
the Google machine reporting 250 are identical.  IPv4 or IPv6 makes no 
difference.  Content and other headers also substantially identical 
(modulo timestamps, queue ids and Message-ID).  Domain does SPF and DKIM 
(but not DMARC).


Simply rewriting the `mumble-mumble-dhcp-mumble` and the dodgy origin 
address with localhost gets the email delivered.


Note that as far as I can tell this is only true for GSuites (and I've 
only tried one list).  Mail to GMail seems to be working fine.


Of course relays do get compromised from time to time, so peeking at the 
first hop is not a completely crazy thing for GSuites to do.  But 
silently dropping the email after accepting feels a little 
disproportionate.  Perhaps a 451 would be more appropriate?


I have no way of knowing if GSuites is actually looking too closely at 
my first-hop Received: headers but that's the only theory I can come up 
with for my emails not arriving on that GSuites list.


Has anyone else seen this?  Brandon, can you comment if this is 
something to beware of?


Thanks.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

[Michael Wise via mailop]

Is this still on-going?
I had heard that it had been addressed week before last...?

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool ?

From: mailop  On Behalf Of David Carriger
Sent: Friday, February 23, 2018 11:29 AM
To: mailop@mailop.org
Subject: [mailop] Microsoft IPs automatically unsubscribing recipients?


I've just received an interesting escalation from our support team. We have a 
customer sending mail to recipients at the following domains:


andromeda.rutgers.edu
apsu.edu
barry.edu
bsu.edu
ccsnh.edu
clarion.edu
cofc.edu
dcccd.edu
gsu.edu
hofstra.edu
king.edu
letu.edu
mail.barry.edu
mansfield.edu
mercycollege.edu
mssu.edu
oldqueens.rutgers.edu
queensu.ca
rci.rutgers.edu
rutgers.edu
salemstate.edu
trevecca.edu
uncfsu.edu
usi.edu
vanderbilt.edu
wcsu.edu


With the exception of Rutgers, these are all hosted on Office 365. Once the 
mail has delivered, I'm seeing all of the links inside the email hit within a 
span of time varying between 1-10 seconds. For example, here's an unsubscribe 
in our database for @mssu.edu:

List Unsubscribe Mon Feb 19 08:45:54 EST 2018 by 40.107.217.27



If I pull my web access logs for that, I've got the following timeline of 
events (all times are EST):



2018-02-19 08:45:55 /app/optOut/noConfirm/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:55 /app/optOut/8/bf58b2859105b738/994494/72f6f3b025bfa2a1  
   40.107.217.27

2018-02-19 08:45:55 /app/emailOpened/994494/924 40.107.217.27

2018-02-19 08:45:56 /app/optOut/noConfirm/994494/%3Cimg%20src= 
40.107.217.27

2018-02-19 08:45:57 /app/hostedEmail/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:59 /app/emailOpened/994494/924 40.107.217.27



So, for this example, within a span of four seconds we've hit the one-click 
opt-out link we use in our List-Unsubscribe header, the user-visible 
unsubscribe link within the message body, the open tracking pixel, the tracking 
link we provide for our customer's call-to-action...that's not human behavior. 
That's machine behavior.



It's the same story for all of the other recipients I've looked at. This 
behavior is occurring from the following IPs/ranges, all owned by Microsoft:



104.47.61.250

40.107.217.0/24

40.107.218.0/24

40.107.222.0/24

40.107.234.0/24

40.107.238.0/24

40.107.242.0/24



Are we the only ones experiencing this, or are others seeing this as well?



Small Business Growth Expert
DAVID CARRIGER
Linux Systems Administrator

--
david.carri...@infusionsoft.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Quick question on Comcast FBL...

[Brotman, Alexander]

So, this isn't truly my part of the platform, but I can tell you that I've 
heard that in some of these cases the things I've heard.  This seems to mostly 
be related to folks switching to a new email client using IMAP.  The new client 
believes it knows better than your last, and begins to reclassify the mail.  We 
once had a guy hooking up his autmobile to read his email, and the email client 
started to reclassify email.  It would only happen when the auto was near his 
home wifi, which made it that much more confusing to troubleshoot.

I believe that they ignore the messages as they are considered too old.  If 
you're still curious, I can double check on that.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Eric Tykwinski
Sent: Monday, February 26, 2018 11:37 AM
To: mailop@mailop.org
Subject: [mailop] Quick question on Comcast FBL...

Just last week I've noticed a sudden uptick on very old spam notifications.  
(Some dated back to 2010...)
Just wondering if anyone else is seeing the same and if Comcast knows about it.
Doesn't seem to be effecting our deliverability, but guessing maybe they did 
some changes.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Quick question on Comcast FBL...

[David Hofstee]

We see it too, down to 2011. This was Feb 7th where someone made note of
that. Of IPs that are not sending email anymore.

Yours,



David

On 26 February 2018 at 17:36, Eric Tykwinski  wrote:

> Just last week I’ve noticed a sudden uptick on very old spam
> notifications.  (Some dated back to 2010…)
>
> Just wondering if anyone else is seeing the same and if Comcast knows
> about it.
>
> Doesn’t seem to be effecting our deliverability, but guessing maybe they
> did some changes.
>
>
>
> Sincerely,
>
>
>
> Eric Tykwinski
>
> TrueNet, Inc.
>
> P: 610-429-8300 <(610)%20429-8300>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>


-- 
--
My opinion is mine.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Quick question on Comcast FBL...

[Eric Tykwinski]

Just last week I've noticed a sudden uptick on very old spam notifications.
(Some dated back to 2010.)

Just wondering if anyone else is seeing the same and if Comcast knows about
it.

Doesn't seem to be effecting our deliverability, but guessing maybe they did
some changes.

 

Sincerely,

 

Eric Tykwinski

TrueNet, Inc.

P: 610-429-8300

 

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] TLS support

[Eric Tykwinski]

> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Angelo Giuffrida
> Sent: Monday, February 26, 2018 3:02 AM
> To: Anthony Chiulli
> Cc: mailop@mailop.org; Brotman, Alexander
> Subject: Re: [mailop] TLS support
>
> Seems that the email client stripped the double forward-slash from the link. 
> Copy the URL exactly as it appears, don't use the hyperlink:
> https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43962.pdf
> Complete with the double forward-slash and everything...


That didn’t work for me either, so I did a quick search:

Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery 
Security Zakir Durumeric† David Adrian† Ariana Mirian† James Kasten† Elie 
Bursztein‡
https://research.google.com/pubs/archive/43962.pdf

I'm assuming that's the document in question.

Did a search on the DMARC mailing list as well originally, since I was 
interested in those stats.
Found this site mentioned for statistics: 
http://secspider.verisignlabs.com/stats.html

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300





___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] TLS support

[Stefano Bagnara]

On 22 February 2018 at 17:00, Stefano Bagnara  wrote:
> We ignore certificate issues and lowered the cypher requirements as
> much as possible.
> We settled to 0.01% failures converting the socket to TLS: most common
> domains involved in the failure are uni-kl.de and univie.ac.at

Just an update because Univie postmaster kindly contacted me offlist
and we analyzed the issue.

Turned out my MTA did not support EC* ciphers so when contacting
uni-kl or univie servers the TLS handshake chose (server chosen) a
DHE_ cipher.

The issue is that both serve use a DH key length that is not "multiple
of 64" (1453bits the uni-kl, 2236bits the univie) and Java fails with
this error "DH key size must be multiple of 64, and can only range
from 512 to 8192 (inclusive). The specific key size 2236 is not
supported".

I'm not a cripto expert so I don't know if this "multiple-of-64"
constraint from Java is a java limit or a cipher specification.

Now, enabling the ECDHE_ ciphers on my side worked around the issue.
It seems the DHE_ cipher have a "limit" because when 2 parties choose
to use it they don't know yet if they will be able to complete the
handshake, while EC* expose the supported curves in the choice phase
so you better know the handshake will work if you agree on that
cipher. I found this article:
https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/AAdv838-koo/discussion

I found many receivers (microsoft, gmail, yahoo) only expose ECDHE_*
and not DHE_* ciphers maybe because of this issue.

Even if enabling ECDHE seems to have fixed most of the remaining
issues, I'm evaluating removing DHE_* ciphers on my client side to
avoid further issues similar to this.

I found https://github.com/mozilla/cipherscan useful, while debugging the issue.

Hope this helps,
Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] TLS support

[Angelo Giuffrida]

Seems that the email client stripped the double forward-slash from the
link. Copy the URL exactly as it appears, don't use the hyperlink:

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43962.pdf

Complete with the double forward-slash and everything...

On Mon, Feb 26, 2018 at 11:40 AM, Anthony Chiulli 
wrote:

> Alex - Link does not resolve for me, 404.
>
> *ANTHONY CHIULLI*
>
>
>
> On Sun, Feb 25, 2018 at 6:21 AM, Brotman, Alexander <
> alexander_brot...@comcast.com> wrote:
>
>> This is a tad dated, but:
>>
>>
>>
>> https://static.googleusercontent.com/media/research.google.
>> com/en//pubs/archive/43962.pdf
>> 
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Alex Brotman
>>
>> Sr. Engineer, Anti-Abuse
>>
>> Comcast
>>
>>
>>
>> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *Matt
>> Vernhout
>> *Sent:* Friday, February 23, 2018 10:53 PM
>> *To:* Michael Storz 
>> *Cc:* mailop@mailop.org
>> *Subject:* Re: [mailop] TLS support
>>
>>
>>
>> Check out Google’s transparency report
>>
>>
>>
>> https://transparencyreport.google.com/safer-email/overview
>>
>>
>>
>>
>>
>> ~
>>
>> Matt
>>
>>
>> On Feb 22, 2018, at 13:04, Michael Storz  wrote:
>>
>> Am 2018-02-22 16:40, schrieb David Hofstee:
>>
>> Hi,
>>
>> A quick question... Does anyone have numbers on:
>>
>> - the (volume) percentage of emails sent via TLS (capable mail
>>
>> servers)
>>
>> - the (volume) percentage of emails sent via TLS where the receiving
>>
>> mta has a valid certificate
>>
>> - the (volume) percentage of emails sent via TLS where the receiving
>>
>> mta uses a valid certificate and supports DANE
>>
>> Any answer is appreciated. Yours,
>>
>> David
>>
>>
>> Hi David,
>>
>> These are the numbers from the last seven days. Outbound traffic from the
>> Munich Scientific Network (several universities). 2/3 of the traffic goes
>> to Google, GMX, WEB.DE, Microsoft and Yahoo. GMX and WEB.DE support DANE
>> (TLSA records).
>>
>> TypeMTAs   Connections
>>
>> Untrusted   3.7752,05 %
>> No TLS  3.2782,36 %
>> Anonymous   3.5344,62 %
>> DANE  157   23,91 %
>> Trusted14.428   67,04 %
>> ---
>>   25.172   99,98 %
>>
>> Michael
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop