Subject: Re: [dmarc-ietf] yet more From rewriting,

From: Douglas Otis <[email-masked]>
Date: Wed, 1 Oct 2014 06:27:33 -0700

On Sep 30, 2014, at 11:59 PM, Stephen J. Turnbull <[email-masked]> wrote:

> Douglas Otis writes:
> 
>> Thank you for your response, but it seems to overlook a few
>> important issues.
> 
> Indeed I overlooked them, but that's because in the context of this
> working group I consider them unimportant.  As follows:
> 
>> The view of DMARC being a private agreement between MX servers
>> assumes services to the general public are normally categorized as
>> common carriers to ensure against discrimination and franchise
>> abuse.
> 
> [...]
> 
>> To overcome misuse of DMARC policies, email reliant services are
>> then FORCED to alter the content of their From header fields into
>> non-compliant forms as their only means to ensure the integrity of
>> their own service.  Such behavior clearly moves DMARC well beyond
>> the realm of private agreements.
> 
> [...]
> 
>> SPF is being used by the Kelihos peer-to-peer botnet variant as a
>> means to create DMARC valid messages [...].   DMARC is also not
>> effective against look-alike attacks [...].
> 
> Abuse of common carrier status is not IETF business, is it?

Again thank you for your thoughtful response.  If only it was abuse of a common carrier status.  Be careful not to take a naive view about what to expect from a large ISP that has had a prolonged series of massive account compromises.  That said, when their proposed solution has a high propensity to impact legitimate email services, such as forums like this one, it is time to find a better alternative.  People should find it disturbing being forced to look into spam folders for messages from officers of a company attempting to make exchanges in similar forums.  It seems they all do it initially and many persist expecting some kind of 'special' treatment.  Talk about dangerous and spurious correlations being given to the common folk.

> As for
> private decisions and agreements having external effects, what else is
> new?  The important content of "private agreement" is that outsiders
> can make all the "standards" they like, but the parties need not adopt
> them and can continue their behavior.  Whether DMARC is effective or
> not is also outside of the scope of this WG.

When DMARC's reject or quarantine policy is applied against normal email accounts held by many millions of typical users, an option whether to mitigate damage to reliant email services, such as that of this forum, can not be considered some kind of adoption option.  In fact, the charter for this WG states:
,---
...DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox (for example, mailing lists, publish-to-friend functionality, mailbox forwarding via ".forward", and third-party services that send on behalf of clients). The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility. Finding methods to better mitigate against the disruption affecting legitimate services is very much within the scope of this WG.
'---

> Bottom line: DMARC is a non-IETF standard prevalent on the Internet,
> and the WG charter takes that as given as far as I can see.  I grant
> that discussion of these issues provides context, but if I choose not
> to discuss them, I don't see a problem for conducting WG business.

Some ISPs seem content taking inadequate measures to address their growing account compromise problems.  Originally, DMARC only ensured customers receiving high-value transactional messages would not see high levels of spoofing the service attracted.  DMARC was never intended to address massive compromises of contacts and credentials, nor is its current form suitable for use with general email.  As such, it seems it is unlikely to be considered suitable as a proposed standard, no matter how prevalent its mis-application becomes.  Haphazard mitigation strategies caused by a laissez-faire approach is likely to incur greater harm and disruption, at the crux of the matter to be handled by this WG, unless I am woefully mistaken.

>> At least adopting a standard DMARC Group exception should give
>> potential victims a clue something is different about the message.
> 
> "Should", yes, I agree in some sense.  Unfortunately, at least one HCI
> paper I read (I am not a specialist) says many potential victims are
> clueless, and most lack some important clues for protecting their own
> security.
> 
> What worries me is that users will pick up on a spurious correlation
> (the same research provides evidence for that) and interpret the
> visible artifacts (such as a DMARC-noncompliant tag) incorrectly.
> Specifically, they'll interpret as just another example of computer
> breakage, and ignore it in favor of their trust relationship with the
> apparent author.

Perhaps the group name might use something more plain, like U+2620 skull and crossbones ☠ or perhaps DMARC-UNKNOWN

> Remember, *we* know that a great majority of all messages getting that
> tag are spam, but *the users* never notice them -- many are discarded
> automatically and those in the spam bucket get discarded without
> thought -- unless the message is actually from a trusted party, which
> validates the "computer is broken" hypothesis from that point of view.

Again, DMARC is not comprehensive since it still permits various look-alike attacks.  Not allowing exceptions results in users checking their spam folders, a far worse practice.

>> In the era of botnets, spammers are able to create DMARC valid
>> messages without much difficulty.
> 
> Who needs a botnet?  Anybody with access to any domain's DNS can do
> that.  I suppose your point is that somebody with a botnet is able to
> send From-aligned messages from a Yahoo! address.  I don't see how
> anything authentication-based can deal with such malicious mail, by
> definition -- the bot must be able to authenticate to send it.  To
> combat such abuse, you need to examine content of outgoing messages as
> well as incoming messages.  "Defense in depth" is the watchword here.
> 
> But that doesn't make DMARC "D for dangerous"or useless.  The point of
> Yahoo!'s and AOL's use case (thanks to Alessandro Veseley here for
> making me aware of this) is that the "acquaintance recommendation"
> spam or phish is based on the ability to spoof a *particular* user to
> another user, and this is based on an *external* (stolen) contact
> list.  A bot can't do that arbitrarily: because of the way message
> submission works, it needs to authenticate to pass DMARC p=reject.

I find less threats reading messages in mailing-lists than in my inbox.  You must be horrified anyone reading these messages can spoof you as me, Alessandro, and others.  How do you cope without DMARC protection?  I too have seen spoofs of friends purporting to be stuck in an airport in Turkey claiming to have lost their wallet and cell phone. 

> I suppose if you have both that list and the list of bots, you could
> match them up and use the "right" bot for this contact list (although
> the number of matches would be a smallish fraction of all contacts, I
> suppose).  (Not to mention that if you have such a 'bot, it seems more
> sensible to just use its contact list if you're going to try
> "acquaintance recommendation spam".)  So apparently that isn't what is
> happening, as p=reject was effective to combat the April attacks.

DMARC represents a poorly considered reaction that disrupts normal email use.  Basic security issues must still be addressed such as sloppy use of SPF for example.  It took TW forever to implement TLS.  Disruptions can be mitigated by DMARC domains' use of TPA-Labels where no other change would be needed, or by adoption of a group label rewrite strategy where users would require some education.  It seems the alternatives are much worse.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 02 Oct 2014 12:41:06 +0900

I think this is going around in circles so I've replied at length
off-list.  This one opinion I wish to respond to on-list, though.

Douglas Otis writes:

 > DMARC represents a poorly considered reaction

Even though I'm a mailing list user, owner, and developer, I cannot
agree.  I *wish* that they had put MLs at the top of the list of
issues when discussing whether to impose "p=reject" or not, but get
serious.  That's really not that big a deal for their users compared
to network disruption and a flood of spam, not to mention falling
victim to fraud.[1]  My conversations with Yahoo! techs indicate that
they are competent, hard-working, and ethical.  I conclude that when
they say "p=reject" was the best option, they mean it and it was
chosen carefully.

True, I don't recall an explicit apology from a Yahoo! tech[2], even
in non-public channels, but I suppose "Yahoo! has something to be
sorry for" is covered by their NDA. :-)  So I give them credit for
*feeling* sorry even if they don't say it. :-)

Footnotes: 
[1]  Please don't respond that they shouldn't have leaked contact
lists in the first place.  That's true, but irrelevant -- these things
happen (I know from experience :-( ), and we should assume they're
going to continue to happen even with state-of-the-art security.

[2]  My memory is fallible, though.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 2 Oct 2014 16:11:51 -0700

> they say "p=reject" was the best option, they mean it and it was

Dear Stephen, 

From your response, I can more clearly understand where our views differ, and for that, thank you.

p=reject should NOT be seen as having been their best policy solution applied against general purpose or public user accounts!  The typical reaction to the disruption they created was to translate their p=reject into p=quarantine.  This reaction also represents a similarly expedient solution.  Not expecting such a reaction would be naive in my opinion.   Also note, those who created DMARC did not expect their protocol to be abused in this manner.  As such, the reaction to the resulting disruption showed a reject policy was not well considered.  Since this also injured competing mailing-lists, some may even view p=quarantine as not ethical especially when applied over an extended duration.  This is why the role of a common carrier was mentioned.  Taking on the role of common carrier would impact ISPs in several interesting ways. :^)

My suggestions were all aimed at extending or tweaking DMARC to be even more effective while not disrupting legitimate services, such as those offered by Intuit as an example.  One was to craft a specific exception list to excuse responsible third-party services employed by their user base.  The other was to have the protocol adopt a highly visible From scheme that permits specific group syntax such as ☠: or DMARC-UNKNOWN: where DMARC would not be applied.  Those promoting DMARC are euphoric for the most part DMARC published policies are being applied.  As these policies become abused with an excuse it offers no means to make exceptions, this success seems destine to fade.  The next stage of abuse seems likely to attack its relatively weak SPF authorization scheme.  If so, we might find ourselves once again looking for a policy assertions effective against a new flood of abuse.  Now that would be a true circle. 

Regards,
Douglas Otis

---

From: Josh Aberant <[email-masked]>
Date: Thu, 2 Oct 2014 16:45:42 -0700

> The typical reaction to the disruption they created was to translate their
> p=reject into p=quarantine.
>

Would you provide some proof of this assertion?

Josh

---

From: "John Levine" <[email-masked]>
Date: 3 Oct 2014 02:23:38 -0000

>Would you provide some proof of this assertion?

I'm not Doug, but Google unquestionably did that when AOL and Yahoo started
publishing p=reject.

R's,
John

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Thu, 02 Oct 2014 20:15:50 -0700

> I'm not Doug, but Google unquestionably did that when AOL and Yahoo started

My day job's product (SonicWall) handles p=reject as quarantine by 
default. The administrator has the option of changing that if they want, 
but it's both the default and the recommend setting in the UI. This was 
based on the broad observation that false positive rate was way too 
high. Yahoo and AOL weren't the sole reasons (bad DKIM and SPF records 
as well as skittishness over our own bugs were factors, too), although 
they were part of the discussion.

<csg>

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 03 Oct 2014 08:52:21 -0500

> default. The administrator has the option of changing that if they 
> want, but it's both the default and the recommend setting in the UI. 
> This was based on the broad observation that false positive rate was 
> way too high. Yahoo and AOL weren't the sole reasons (bad DKIM and SPF 
> records as well as skittishness over our own bugs were factors, too), 
> although they were part of the discussion.

More or less the same for mine (MDaemon).  I do not honor p=reject by 
default.  What I did was insert a header in the message for the 
filtering modules down-stream to treat it like p=quarantine (or p=none 
for that matter if that's what the admin/user wants to do).

Arvel

---

From: Brandon Long <[email-masked]>
Date: Fri, 3 Oct 2014 15:41:36 -0700

> I'm not Doug, but Google unquestionably did that when AOL and Yahoo started

We didn't change anything at that point.  We already had code for treating
some specific cases as p=quarantine where we expected the messages were
unable to pass SPF or DKIM.  Its not a blanket thing, and we expect it will
be tightened up over time ... especially if phishers figure out how to
spoof it.

Brandon

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 04 Oct 2014 14:09:21 +0900

> > I'm not Doug, but Google unquestionably [started translating
 > > p=reject into p=quarantine] when AOL and Yahoo started publishing
 > > p=reject.

 > some specific cases as p=quarantine

If you can answer, I'd like to know: would Google have introduced that
code if DMARC were a standards track RFC?

If Google would likely not conform even to a standard, given the
testimony from several other vendors as well, I consider the current
protocol irretrievably broken (ie, it's almost a no-op) in this one
respect.

Where I would go with this: I have long thought that the current "p"
definition, which tells the receiver "what to do", is inappropriate
because it is uninformative about the nature of the email (by
definition the From Domain doesn't know, because that domain didn't
handle the email in current form!), and often conformance is *very*
much against the receiver's interests (who *does* know exactly what
they're looking at).  I would prefer an informative definition that
describes the Domain Owner's *sender* policy.[1]

Regards,

Footnotes: 
[1]  Here's what I have in mind.

Note that this text MUST NOT be construed as a proposal by me to amend
the DMARC protocol at this time.  Of course I'd be thrilled if the
editors of the draft informative RFC chose to adopt it, but at the
present point of time I consider it equivalent to "asking for a pony".

   p: Domain Owner origination policy (plain-text; REQUIRED for policy
      records).  Indicates the policy published to mailbox users by
      the Domain Owner.  Policy applies to the domain queried and to
      sub-domains unless sub-domain policy is explicitly described
      using the "sp" tag.  This tag is mandatory for policy records
      only, but not for third-party reporting records (see Section
      7.1).  Possible values are as follows:

      none:  The Domain Owner imposes no sending policy on mailbox
          users, and failure of the DMARC mechanism check MUST be
          considered equivalent to absence of DMARC mechanisms.

      suspicious:  The Domain Owner does not prohibit indirect email,
          but warns Mail Receivers that email that fails the DMARC
          mechanism check is likely to be mischievous or malicious.

      prohibited:  The Domain Owner prohibits indirect email.  Mail
          Receivers are authorized by the Domain Owner to reject all
          email that fails the DMARC mechanism check.  Rejection
          SHOULD occur during the SMTP transaction.  See Section 15.4
          for some discussion of SMTP rejection methods and their
          implications.  Third parties SHOULD NOT transmit email with
          this From Domain.  [Mediators which perform transformations
          of email known to cause failure of the DMARC mechanism check
          MAY proactively reject email received for redistribution,
          even though as received it passes the DMARC mechanism check.]

      quarantine: (Obsolete) MUST be treated as equivalent to suspicious.

      reject: (Obsolete) MUST be treated as equivalent to prohibited.

      Rationale: "quarantine" and "reject" were defined with somewhat
      different semantics in a previous version of this standard, but
      the non-conformant practice of giving them the semantics defined
      here was observed to be widespread among Mail Receivers.

I probably have some of the technical terms wrong.  The part in
brackets is probably wishful thinking on my part, although in practice
I expect some Mediators to behave that way even if the MAY amended to
MUST NOT.  Note that because it requires a DNS check etc, and the
third parties are typically *not* party to agreements not to send with
the Domain owner, I don't think the prohibition on third party email
should be strengthened to MUST NOT.  "Reasonable effort" is really all
you can ask of third parties in general.

---

From: Patrick Peterson <[email-masked]>
Date: Sat, 4 Oct 2014 10:40:04 -0700

> protocol irretrievably broken (ie, it's almost a no-op) in this one
Just a point of clarification. The current DMARC spec [B.3.1] states
“...the Mail Receiver applies the DMARC-record-specified policy.
   However, before this action is taken, the Mail Receiver can consult
   external information to override the Domain Owner's policy. “

So it is my understanding that a receiver can both conform to the spec and not honor the sender policy. I believe that was the intent as receivers will not honor a policy of they believe it is the wrong thing to do for their users.

Additional note: one nice feature is that the aggregate DMARC data indicates when the policy has been overridden enabling the domain-owner to see what mail sources and percentage of email has a different disposition that intended. This is powerful as the domain owner can determine the magnitude of the issue and determine whether the overridden mail is likely malicious or an issue of authentication issues.

pat

---

From: Josh Aberant <[email-masked]>
Date: Sat, 4 Oct 2014 13:31:28 -0700

> publishing p=reject

Again, this is an assertion and where is the evidence for this?

The reason I ask for evidence is that this doesn't match what we've seen at
Twitter.  Google's already replied on this list that they didn't change
anything because of Yahoo & AOL. We observed Google's transitive trust
stuff long before those ISPs made their moves to protect their users.

More importantly, there continues to be very real and significant
differences between reject & quarantine. #RejectPolicies result in a whole
lot of bounces which are both better user protection and also probably very
discouraging for the bad guys.

Thanks to SonicWall and MDaemon for their replies on their approach. While
I very much appreciate the goal of reducing false positives, I would also
like to reply that enabling a #RejectPolicy tends to be a very considered
move. The senders I know with a current #RejectPolicy all had spent many
months inventorying their mailstreams prior - they knew what would be
"false positive" long before they turned it on.

Josh

---

From: "John Levine" <[email-masked]>
Date: 4 Oct 2014 21:34:35 -0000

In article <CAKXPkzs_PM=BhkZW0WsjERXGyMV3aeD_eshORxy=sAcn=[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-

Tech people at Google told me that's what they did.

R's,
John

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 05 Oct 2014 18:03:33 +0900

> Just a point of clarification. The current DMARC spec [B.3.1]

Thank you for pointing this out.  You are quite correct, as Section 6
(Policy Enforcement Considerations), paragraph 2 says clearly:

   Mail Receivers MAY choose to accept email that fails the DMARC
   mechanism check even if the Domain Owner has published a "reject"
   policy.

As well as other language specifying that final disposition of a message
received is, as it always has been, at the discretion of the receiving
system.  Nor has this changed in the current version of the next draft
that Murray is working on.  I should be more careful to read the
document.

However, AFAIK it is inappropriate to cite an Examples Appendix as
though it were normative.

 > So it is my understanding that a receiver can both conform to the
 > spec and not honor the sender policy. I believe that was the intent
 > as receivers will not honor a policy of they believe it is the
 > wrong thing to do for their users.

Indeed.

I still think the choice of describing the protocol in terms that give
the Domain Owner, who has no idea what's in the mail, the power to
decide disposition was a bad idea, especially since the actual
language shows definitively that that is not the case!

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 05 Oct 2014 18:16:24 +0900

Josh Aberant writes:

 > The senders I know with a current #RejectPolicy all had spent many
 > months inventorying their mailstreams prior - they knew what would
 > be "false positive" long before they turned it on.

This certainly wasn't true for Yahoo! and AOL.

And it's certainly of no consolation to the thousands of other users,
completely unknown to Yahoo! and AOL, whose list service was
interrupted or terminated because of those "false positives".

Finally, while transactional mail streams probably had rather
predictable lack of visible effect on their authentic messages,
authentic Yahoo! and AOL messages were rejected en masse from some
mailing lists because the operators had no other way to protect their
lists from the bounces.  AFAIK nobody anticipated that side effect.

I have to wonder if Yahoo! (and AOL) anticipated the havoc they would
create with business mail streams (such as billing services).  AFAIK
DMARC reports don't provide that kind of information.

---

From: Hector Santos <[email-masked]>
Date: Sun, 05 Oct 2014 10:51:15 -0400

> Again, this is an assertion and where is the evidence for this?

Hi Josh.

I'm Hector. I own http://www.santronics.com.

To explore what will happen with several of our domains, I created 
DMARC "p=reject" records for them.  I used my wizard and simulator to 
create records at:

    http://www.winserver.com/public/wcdmarc

I added logic to our current system that already support 
DKIM+ADSP+ATPS but only from a recording standpoint -- no action is 
taken on ADSP/ATPS policy results.  I have a similar wizard for 
http://www.winserver.com/public/wcADSP.  I did a plug and play for 
wcDMARC and just recording stuff.  But the proof of concept (and 
issues) has long been known.

Anyway, Google was indeed moving my isdg.net posted mail for the IETF 
LIST into a spam box.  My domain mail is signed my our edged outbound 
server (see attached image) as a 1st party signature.  The mail sent 
for the ietf-list was processed by the IETF receiver and list 
processor. It was now no longer a  valid 1st party signature (1PS) for 
the distribution but a valid 3rd aprty signature (3PS). That means all 
DMARC compliant downlinks could either REJECT or QUARANTINE mail.

The EASY SOLUTION is to support 3rd party signer (3PS) protocol 
solutions as envisioned since day uno!

The idsg.net DMARC record when I had it as a "p=reject" would be:

   "v=DMARC1; p=reject; atps=y; rua=mailto:[email-masked]; 
ruf=mailto:[email-masked];"

The atps=y is the ADSP EXTENSION used for DMARC now that would tell 
the receiver to support RFC6541

         http://tools.ietf.org/html/rfc6541

It was one extra lookup. You can use the above wizard to generate a 
hash record for the IETF.ORG domain and the supportive DMARC receivers 
would just a hash lookup for the 3rd party IETF.ORG Domain.

Done, simple!   I have ATPS records for a few others:

e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT	( "v=atps01; 
d=megabytecoffee.com;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT	( "v=atps01; 
d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT	( "v=atps01; d=gmail.com;" )
n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT	( "v=atps01; d=mipassoc.org;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )
q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT	( "v=atps01; d=isdg.net;" )
rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT	( "v=atps01; 
d=mapurdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT	( "v=atps01; 
d=santronics.com;" )

All of those domains are authorized 3rd party signers (3PS).   So as 
you can see, the other side of the coin here -- scalability and 
management of large list of authorized domains.  I don't see it as a 
problem.  But thats me.

Yahoo should be having a WIZARD that allows them to AUTHORIZED 3PS 
domains that wish support end  users with those domains.  If they 
don't want to do that, thats a different issue all together that the 
LIST people don't really like.  Their push to REWRITE isn't going to 
work and when the bad guys begin to explore it, well... I hate to see 
that happen if not already too late.

> stuff long before those ISPs made their moves to protect their users.

I saw Brandon's post. I scratched my head.  They were indeed 
separating it when my record was p=reject. I changed it to p=none 
because I don't want any negative potential "learning" and R&D going 
on out there.

> discouraging for the bad guys.

You appear are a strong advocate for rejection. We could of used you 
back in the SSP/ADSP days. ADSP was IETF standard track, you know and 
it was made historic just last year or so so that should tell us that 
there is going to be HIGH resistance for DMARC by the list or 3rd 
party mail distribution market.

FOLKS -- SUPPORT 3PS solutions and everyone can have their cake and 
eat it!  It is the LEAST COST and ULTIMATE SOLUTION as oppose to the 
kludgy, complex way people what to fit a LIST system into the untold 
variant forms of mail networks!

> "false positive" long before they turned it on.

This solution for all this was long known but only by the strong 
policy advocates. I explored it all.  SSP/ADSP/DSAP and stopped short 
with DMARC because it didn't solve this exact problem and it was going 
to have the same problem until some key IETF people begin to change 
their tune about DKIM POLICY frameworks,.

The original DKIM had 3rd party options. It was split as DKIM+SSP.  I 
recall Avrel and I believe that was not a good idea. But it went that way.

SSP got too bit complex too much and lost, again among the the swamp 
of indirect and MAIL LIST usages that is going on now, again, repeated.

I attempted to simplified it with DSAP

     http://tools.ietf.org/html/draft-santos-dkim-dsap-00

and was ready to an IETF meeting to begin to champion it, even made 
the PPS slides for it:

      http://www.winserver.com/public/sap/DSAP.pdf

which removed all the subjective OPERATIONAL stuff and just provided 
the technical protocol framework based off its boundary conditions for 
all the potential combination of results.   All usages had to fall in 
one of the sets of process parameter values for 1SP and 3PS  values:

    1SP (_) MUST  (_) OPTIONAL (_) NEVER
    3SP (_) MUST  (_) OPTIONAL (_) NEVER

etc.

Levine created ADSP, a reduced version of SSP that in short tried to 
IGNORE LIST considerations.  1st party wishes MUST NOT IMPUGN on the 
needs of the 3rd party operations.   It was flawed.

Unfortunately, ADSP became was standard track but never supported by 
its author, levein.  I created ASL "Allowed Signer List" to fix it 
which was a extension of ASDP, a tag that listed the authorized list 
of 3rd party signers.  Doug Otis created TPA (Third Party 
Authorization) which piggybacked off ADSP as well and Murray created 
ATPS (Authorized Third Party Signer) (rfc6541).

We didn't have the politic power to push this the DKIM PLUS POLICY 
framework. The push was for a DKIM + TRUST network using the DKIM 
signer domain (SDID).

I added support DKIM+ADSP+ASL+ATPS into Wildcat!  I think Murray added 
DKIM+ADSP+ATPS into Sendmail. I don't know what Arvel did with ADSP 
but he provided a open source DKIM C++ API with a ADSP optional 
functional hook. We used for our package. I vastly extended it for 
ADSP, ASL, ATPS and VBR, adding p-code language import hooks into our 
server-side scripting code where operators can create their own 
scripting rules.

In fact, all the early DKIM APIs always had POLICY support. 
Domainkeys had it built-in.  Its clone called DKIM with an expanded 
policy set.   To push DKIM as a standard, the policy part was 
separated as SSP.  It became standard track when Levine did ADSP. ADSP 
was hampered by a lack of desire to champion it by its authors who 
preferred the TRUST framework instead.   DKIM became a STD, the same 
folks killed ADSP and then reintroduce the POLICY idea via DMARC.  But 
it only did 1PS. It didn't do the 3PS part.

So that is where we are at.

Try this. Add support for the DKIM+DMARC+ATPS as I explored it with 
the WIZARD. Create a few domains to authorized and it will WORK.

That problem is the scale of all this.  I don't see that as a problem. 
Its doable.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 05 Oct 2014 11:41:10 -0400

I should add that if a system is not currently capable of accepting 
policy-failed transactions and separating it into an user's "spam box" 
then it SHOULD honor the Reject and reject the mail at SMTP.

In other words, using quarantine for reject instead is only for 
systems that CAN  separate the mail at ALL MUA type levels; online, 
offline and hybrids MUAs.

Otherwise there is a security hole.  Keep in mind that any protocol is 
generally OK as long the same security functional goals are achieve 
with the options of the protocol.   Not honoring the reject and just 
accepting it with no separation is a SECURITY HOLE.

If the USER is a POP3 user, in general, this is a single stream of 
mail collected and giving the the POP3 client.  Its not like IMAP. 
The POP3 MUA will need to be able to separate it.  On the other had, 
an IMAP client and/or the backend with a more modern Online HTML view 
or even downloaded frontend end client can separate the mail more 
easily.

But the backend has to be ready for this separation.  If it can not, 
it SHOULD NOT be ignoring the p=rejects and SHOULD perform the reject 
at SMTP.

-- 
HLS

On 10/4/2014 4:31 PM, Josh Aberant wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>