Hello Doug, my understanding is, that SPF complements DKIM only in the cases, where the MTA is not capable to sign an email, e.g. a bounce.
So, if your MTA can DKIM-sign everything, you do not need SPF. > Do you handle SPF any differently between senders with DMARC enforcement and > those without? No, SPF does not work with aliases (where no SRS is applied). My experience sending email over a mailing list to some domains directly and to the same domains indirectly (over other hosts, which in fact do aliasing) for a DKIM signature that failed is, that due SPF the direct emails were delivered, whereas the indirect emails were not. This also created indirect feedback, that is not in my logs very precise. So I concluded to remove SPF TXT records and next time such things happen, I can check in the logs which message in particular was rejected and maybe avoid such situations in the future. Regards Дилян On Thu, 2019-03-21 at 14:36 -0400, Doug Foster wrote: > I am all for anything that cuts unwanted email. Not sure of the need to > distinguish between spam and phishing. > > I am assuming that I am the only one in this group not using DMARC. You > heard my problems with SPF. > > What do you do for SPF Exceptions? > · We have never seen a legitimate sender who needed an exception? > · We whitelist the source IP address and trust that it will only be > used for appropriate domains? > · We whitelist the sender domain and hope it will never be spoofed? > · Something else? > > Also, how do you handle SPF non-pass: Neutral, Softfail, Syntax errors, or > Excessive nesting > > Do you handle SPF any differently between senders with DMARC enforcement and > those without? > > Doug Foster > > > From: dmarc [mailto:[email protected]] On Behalf Of Ken Simpson > Sent: Thursday, March 21, 2019 1:01 PM > To: John R Levine > Cc: IETF DMARC WG; Dotzero > Subject: Re: [dmarc-ietf] Email security beyond DMARC? > > > > I'm going to have to disagree with you John. DMARC is about preventing > > > direct domain abuse. It does not specifically address phishing as the bad > > > guys can simply use cousin domains, homoglyphs, etc. > > > > Well, it's abount a subset of phishing. It's surely more about phishing > > than about spam. > > > IMHO, by cutting out direct domain spoofing, DMARC makes it easier for > receivers to craft algorithms that spot impersonation attacks. Once you have > configured DMARC, receivers can build - for example - a machine learning > system that learns what your legitimate email looks like. They can use that > same system to identify messages that look like your legitimate email but > which do not actually originate from your domain. > > If you want to detect domain impersonation or "brand" impersonation, you > first have to have a verifiable ground truth corpus. That is what DMARC > offers. > > Regards, > Ken > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
