On 06.05.17 15:49, Thore Boedecker wrote:
After looking at the headers it became clear what the issue was:

It seems that Yahoo (at least yahoo.co.jp) is allowing emails from
@gmail.com senders to be sent through their servers.

From: Matus UHLAR - fantomas <uh...@fantomas.sk>
@gmail.com From: and envelope from. Sender: was yahoo...

On 06.05.17 17:55, David Jones wrote:
The headers imply that this was sent from the Yahoo webmail
interface which must allow users to setup an "identity" like
Thunderbird does that allows custom From: and Return-Path:
headers.  They shouldn't allow this in their webmail interface.

They should not, but this has nothing to do with the DKIM itself.


BTW, their webmail interface should also add an X-Originating-IP:
header of the client so we could tell which country it was sent
from.  I bet it wasn't Japan.

Received: header should do that as well:

Received: from [37.130.224.21] by web101313.mail.kks.yahoo.co.jp via HTTP;
        Sat, 06 May 2017 21:41:47 JST

Hosting Services Inc, GB

I did test SA run and it did parse the header.

The funny thing is, that there is a @gmail.com address in both the
'From:' and 'Return-Path:' headers, but a @yahoo.com address in the
'Reply-To:' and 'Sender:' headers.
Somehow Yahoo sees no problem in that and is happy to DKIM sign those
emails with a correct *Yahoo* signature.

I wonder why didn't THE mail hit SPF_SOFTFAIL, since it was supposed to...

The email didn't go through a Google mail server and the envelope-from
was yahoo.co.jp so SPF should have passed based on IP 183.79.57.110.

Return-Path: <haouaouchawa...@gmail.com>

that's not yahoo address (Return-Path is set to envelope from by MTAs).

Also, the mail SHOULD hit SPF_* rule, if the SPF plugin is loaded, but there's 
none.

maybe because:

May  6 22:19:09.740 [30047] dbg: spf: relayed through one or more trusted 
relays, cannot use header-based Envelope-From, skipping

... caused by Received: line containing localhost. the OP should set up spf policyd on valhalla.nano-srv.net...


yes: while we can agree that gmail.com is not yahoo's domain, how can DKIM
validator know?

Yahoo should stop allowing their webmail interface to control the From:
and Return-Path: headers.  I bet this spammer tried to send the email out
from Google which blocked it so this is a way to abuse the Yahoo mail servers
that are not good at blocking the outbound spam.

I doubt Return-Path was set by the sending user, I believe it was set from
envelope from.

I'm listening if you can proove the opposite.

I don't think this problem lies at DKIM verification, more on
trustworthinedd of yahoo who signs such mail,
and the fact of missing SPF checks that I pointed out above.

DKIM does authentication and this email was from Yahoo.  Note no
DKIM_VALID_AU since the From: header was gmail.com.

that is in fact change in requirements on DKIM itself...

I bet as we see DMARC gain traction like SPF has this will force these
major mail hosting providers like Yahoo to shape up.  Right now they are
so big that we can't make them act responsibly.  Yahoo should start rejecting
email that is sent through them like this to prevent spammers abusing them.

Google is slowly turning up the heat with DMARC which forces the Internet
to implement it.  I know this is a pain but I went through this pain a few years
ago and now I am glad to see Google using their influence for good.  In a few
more years all of our spam filtering will be better because of this.

Still - this this is not a problem of DKIM itself and comparing DKIM domain
with envelope from will not fix that - it will only break other forwards.

For now the main problem at receiver's side seems to be missing SPF results.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
M$ Win's are shit, do not use it !

Reply via email to