Seth, you are correct, these message are not in dmarc alignment. And you are also correct, SPF operates on the envelope sender and then dmarc compares the envelope sender, the from addy in the header, and the dkim to ensure all are in alignment. These messages are being sent from the amazonses.com domain, hence why dkim passes as does spf beacuse Amazon has all of those setup correctly. Amazon actually has some useful articles <http://docs.aws.amazon.com/ses/latest/DeveloperGuide/spf.html>. One, if you are not authenticating any of your mail, like amfug, don't do anything and Amazon will take care of it for you. They sign dkim for their own domain and have an spf record. Google (and other mail servers and clients) use dkim to figure out who is sending the mail, hence why Gmail delivers the mail like this:
Gmail sees that it wants to come from the amfug.com domain but it is actually coming from a different domain. To truly make the mail come from amfug.com, they need to: 1.) Get an spf record that covers ses (there is currently no spf record on amfug.com) 2.) Use manual dkim for ses <http://docs.aws.amazon.com/ses/latest/DeveloperGuide/manual-dkim.html> through Amazon's api (which I believe is already being used for this list). Right now Amazon's "easy dkim" is using their own domain and record. You can have your own dkim key and use it for your own domain with ses. This gets rid of the Gmail issue above, how Outlook displays "On behalf of", etc. Unfortunately, each mail client handles the display of these differently. 3.) Setup a dmarc record with no action (no quarantine or reject). This will start logging all of the mail delivery from some of the larger providers and demonstrate where all of the mail is coming from. Once confident all of the sending servers have been captured by at least SPF and preferably dkim, they can turn on quarantine and then reject later on down the line. dmarcian.com, dmarcanalyzer.com or return path all have online tools to receive dmarc reports to and is a million times better than manage the xml on your own. All that said, opinions are like a-holes, everyone has them and they all stink. Paul & co, thank you for taking this on and dealing with all the heat for doing it. Change is never easy. Robbie Wright Siuslaw Broadband <http://siuslawbroadband.com> 541-902-5101 On Fri, Oct 31, 2014 at 10:40 AM, Seth Mattinen via Af <[email protected]> wrote: > On 10/31/14, 9:38, Robbie Wright via Af wrote: > >> You're correct Seth, there is a difference between the envelope sender >> and the mail from address.In the case of DMARC, it requires that the >> envelope sender domain match that of the dkim domain and that of the >> mail from domain to achieve what they call alignment. >> >> I can't recall who did the move, but they chose option number 3a here: >> http://www.dmarc.org/faq.html#s_3 >> >> I agree, not seeing the original sender's email addy isn't ideal. From a >> mail sending stand point, the list is doing it correct (in my opinion) >> but it does make it a little less usable. >> >> > I can't really agree anything right is happening. Most glaringly, > threading has been fubar'd to all hell and my AFMUG folder now looks like a > post-apocalyptic wasteland of disarray. Maybe most aren't used to clients > that do real threading or have separate "Reply" and "Reply List" functions, > but I can't stand how this list now operates. > > The thing is that what it says about DMARC isn't happening here: > > "DMARC introduces the concept of aligned identifiers. Briefly, it means > the domain in the RFC5322.From header must match the domain in the "d=" tag > in the DKIM signature for DKIM alignment, and/or match the domain in the > RFC5321.MailFrom field for SPF alignment." > > "Take ownership of the email message by changing the RFC5322.From address > to one in the mailing list's domain, and adding a DKIM signature for that > domain. Several variations are covered below." > > In the headers the DKIM signature has "d=amazonses.com" where From is " > afmug.com". That doesn't look like what DMARC calls alignment to me. > Since SPF historically operates on the envelope sender, not the from > header, that's always worked before DMARC. However, tweaking an SPF > implementation to start checking the From header would reject lots of > things with an -all policy. > > > And on a side note, next time I'm in Tahoe, I'd love to buy you a beer >> and talk about TahoeIX. I love the idea of smaller IX's like that and >> would love to see/hear what you guys are doing. >> >> > > Sure, I'd happy to give a tour of what's set up for the IX and go into the > details. It's still quite small due to just being started in September, but > it's pretty exciting. > > ~Seth >
