>> Okay, this header is actually defined in RFC 5451, see here: >> >> https://tools.ietf.org/html/rfc5451 > >Is that still valid? The top of the linked page indicates that >RFC 5451 is obsoleted by RFC 7001 (in turn updated by RFC 7410).
Ah, my bad ... I missed that. The updated RFC has some new stuff, but I don't think it changes anything for the purposes of this discussion. >This was sent using GMail's web interface, so it's about as >"legitimate" as it can be. No failing SPF, DKIM, and DMARC tests >(as far as I can tell). Hm, if you got this from the web interface ... I do not think then this is our problem. Breaking the Received headers down (I've reversed them): >> Received: from localhost.localdomain (c-71-202-61-143.hsd1.ca.comcast.net >> <http://c-71-202-61-143.hsd1.ca.comcast.net>. [71.202.61.143]) >> by mx.google.com <http://mx.google.com> with ESMTPSA id >> dx6sm10044832pab.14.2015.03.01.14.04.09 >> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); >> Sun, 01 Mar 2015 14:04:09 -0800 (PST) Okay, this looks like the submission from your local machine to the Google mail servers, which is correct. >> X-Received: by 10.70.44.203 with SMTP id g11mr42282044pdm.130.1425247450905; >> Sun, 01 Mar 2015 14:04:10 -0800 (PST) I guess this is put in there by Google? >> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; >> d=gmail.com <http://gmail.com>; s=20120113; >> h=message-id:from:originator:to:cc:reply-to:subject:in-reply-to >> :references:mime-version:content-type:content-transfer-encoding:date; >> ________ >> ________ >> ________ So that's the DKIM signature from Google. >> Received: by pdbfl12 with SMTP id fl12so3394322pdb.5; >> Sun, 01 Mar 2015 14:04:10 -0800 (PST) Looks like something internal to Google. >> Received: from mail-pd0-f179.google.com <http://mail-pd0-f179.google.com> >> (mail-pd0-f179.google.com <http://mail-pd0-f179.google.com> [209.85.192.179]) >> (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) >> (No client certificate requested) >> by mx3.stanford.edu <http://mx3.stanford.edu> (Postfix) with ESMTPS id >> 5585080B25; >> Sun, 1 Mar 2015 14:04:11 -0800 (PST) So that's Google sending it to Stanford (specifically, mx3 at Stanford). Normal. >> Received: from mx3.stanford.edu <http://mx3.stanford.edu> (mx3.stanford.edu >> <http://mx3.stanford.edu> [171.67.219.73]) >> by pps01.stanford.edu <http://pps01.stanford.edu> with ESMTP id 1sva6d059f-1 >> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); >> Sun, 01 Mar 2015 14:04:13 -0800 That's mx3 sending it to another host at Stanford. >> Received: from pps.filterd (pps01.stanford.edu <http://pps01.stanford.edu> >> [127.0.0.1]) >> by pps01.stanford.edu <http://pps01.stanford.edu> (8.14.5/8.14.5) with SMTP >> id t21M03ir010851; >> Sun, 1 Mar 2015 14:04:14 -0800 Looks like it's running it through some filtering host/program. >> Received: from pps01.stanford.edu <http://pps01.stanford.edu> >> (pps01.stanford.edu <http://pps01.stanford.edu> [171.67.214.163]) >> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) >> (No client certificate requested) >> by mx4.stanford.edu <http://mx4.stanford.edu> (Postfix) with ESMTPS id >> 9A8DC80CD1; >> Sun, 1 Mar 2015 14:04:12 -0800 (PST) I'm unclear how mx4 got involved here, but whatever. >> Received: from mx4.stanford.edu <http://mx4.stanford.edu> (mx4.stanford.edu >> <http://mx4.stanford.edu> [171.67.219.87]) >> (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) >> (No client certificate requested) >> by smtp-grey.stanford.edu <http://smtp-grey.stanford.edu> (Postfix) with >> ESMTPS id AB17E20B81; >> Sun, 1 Mar 2015 14:04:12 -0800 (PST) mx4 sends it to smtp-grey.stanford.edu. >> Received: from smtp-grey.stanford.edu <http://smtp-grey.stanford.edu> >> (smtp-grey.stanford.edu <http://smtp-grey.stanford.edu>. [171.67.219.78]) >> by mx.google.com <http://mx.google.com> with ESMTPS id >> bd5si10126741pbb.59.2015.03.01.14.04.12 >> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); >> Sun, 01 Mar 2015 14:04:14 -0800 (PST) >> Received-SPF: softfail (google.com <http://google.com>: domain of >> transitioning [email protected] <[email protected]> does not designate >> 171.67.219.78 as permitted sender) client-ip=171.67.219.78; >> Authentication-Results: mx.google.com <http://mx.google.com>; >> spf=softfail (google.com <http://google.com>: domain of transitioning >> [email protected] <[email protected]> does not designate 171.67.219.78 as >> permitted sender) [email protected] <[email protected]>; >> dkim=fail [email protected] <http://gmail.com>; >> dmarc=fail (p=NONE dis=NONE) header.from=gmail.com <http://gmail.com> Oh-HO. Okay, I think I see the problem. smtp-grey.stanford.edu is doing the SPF check, but it's getting the email from mx4.stanford.edu! Which is not an authorized sender for Google. But I do not understand why DKIM and DMARC are failing. I am wondering if maybe that's the core problem here. So ... that would make sense. If you're using sendmail, it is performing final delivery NOT through Google, and no DKIM signature is generated. Now, why is the DKIM signature failing? Good question! I don't have a lot of experience with DKIM, but you have piqued my curiousity; if you are willing to send me the original message to me off-list (please base64 encode it so nothing is altered) I'll try to get some free time to chew on it. It may be that we're doing something wrong that is causing this. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
