Subject: Re: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution")

From: "J. Gomez" <[email-masked]>
Date: Fri, 1 May 2015 12:01:00 +0200

On Thursday, April 30, 2015 7:19 PM [GMT+1=CET], Scott Kitterman wrote:

> On Thursday, April 30, 2015 10:00:46 AM Kurt Andersen wrote:
> > On Thu, Apr 30, 2015 at 9:06 AM, Scott Kitterman
> > <[email-masked]> 
> > 
> > wrote:
> > > It might be useful though to have some opt-in mechanism for DMARC
> > > senders to
> > > get an additional query for verification purposes.
> > > 
> > > Concept:
> > > 
> > > Participating senders add a new optional tag to their DMARC
> > > record, something
> > > like yaimfs=y and a new field in the header that is something
> > > like: 
> > > 
> > > yaimfs-id: localpart@domain
> > > 
> > > Domain must be aligned with the From domain
> > > 
> > > For mail that passes DMARC, no changes are made.  If a message
> > > fails DMARC checks and both the DMARC record (which is already in
> > > the local cache) has yaimfs=y and the message has yaimfs-id is
> > > possible, then the receiver sends a
> > > DNS query to message-id.yamfsidlocalpart._dmarc.domain.  The
> > > sender then replies pass/fail/error.
> > > 
> > > I suggest message ID be included since it's supposed to be
> > > globally unique to
> > > reduce the risk of collision.
> > > 
> > > This idea effectively would create a new authentication protocol
> > > based on direct query/feedback and extend DMARC to use it.  It
> > > would be totally opt-in.
> > 
> > Interesting idea - essentially it would allow senders to provide an
> > independent authorization channel for messages. What worries me, is
> > why a sender would sanction a message that presumably has been
> > sufficiently altered as to fail DKIM validation without knowing
> > something about the content as received.
> > 
> > It seems somewhat like saying that if you get a check (the
> > old-fashioned paper kind), that if you call me and tell me what
> > color the paper is, then you can cash the check (presuming that the
> > color is correct). I would not, personally, be granting any such
> > approvals. 
> 
> I think it's a bit more than that.  It's more like "Give me the
> serial number" "Oh, I just wrote a check with the number 30 seconds
> ago, OK" 
> 
> I agree it's not a 100% secure solution since there's a replay risk,
> but the risk is less than with the fs= proposal.

If the message as received at the final recipient is failing the DMARC check, then it comes from a non-authorized IP (regarding the domain in the Header-From) and has an invalid/none DKIM signature (regarding the domain in the Header-From). Anyone could grep the yaimfs-id: of such a message, see that a query to message-id.yamfsidlocalpart._dmarc.domain. passes, and build in the spot a 5 million messages Cryptolocker campaign.

Regards,
J.Gomez

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 01 May 2015 07:39:49 -0400

On Friday, May 01, 2015 12:01:00 PM J. Gomez wrote:
> If the message as received at the final recipient is failing the DMARC
> check, then it comes from a non-authorized IP (regarding the domain in the
> Header-From) and has an invalid/none DKIM signature (regarding the domain
> in the Header-From). Anyone could grep the yaimfs-id: of such a message,
> see that a query to message-id.yamfsidlocalpart._dmarc.domain. passes, and
> build in the spot a 5 million messages Cryptolocker campaign.

Almost.  You only get a pass if the originator says so, so they have the 
ability to limit this to no more than whatever local policy would specify.  
That's the difference in exposure between this proposal and the fs= proposal.  
In this proposal the sender is in full control of how many times to say yes.  
With fs= the most that could be done is put a time limit which , if too short 
causes other operational problems.

Scott K