Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Thu, Apr 9, 2015 at 11:25 AM, John Levine wrote: > Yeah, now that I look at your drafts again, I see that we are both > making the same assertion that this message is a mutated version of > one that someone else sent. I still like mine better because trying > to enumerate all of the possible kinds of changes doesn't work very > well, e.g., subject tags and per-recipient S/MIME encryption. (Sympa > can do the latter.) What we're claiming is slightly different. Your approach is to trust that the "fs" domain isn't malicious; mine is to claim responsibility for only the original content and allow the second domain to claim its modifications. I guess it depends on which side we want to mess with more. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC panel at RSA, 4/22 @ 10:20AM
For anybody who will be attending the RSA Conference in San Francisco about a week and a half from today, there's at least one panel focused on DMARC: "Curbing Email Threats & Spearphishing– The Promise & Results with DMARC" Wednesday, April 22nd, 10:20 - 11:10AM, West, Room 2018 Session code TECH-W03 Email is the most effective cyberattack vector, targeting users and businesses by initiating account takeovers, driving identity theft and serving as the data breach gateway. This session will share research into worldwide adoption of email authentication and DMARC, to show which technologies are proving to be effective countermeasures to thwart social-engineering email exploits and spearphishing. Featuring: Craig Siezle, OTA John Scarrow, Microsoft Trent Adams, PayPal Pat Peterson, Agari Link: https://www.rsaconference.com/events/us15/agenda/sessions/1743/curbing-email-threats-spearphishing-the-promise Enjoy, --Steve. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ideas for list handling
On April 8, 2015 9:47:39 PM EDT, Steve Atkins wrote: > >On Apr 8, 2015, at 5:32 PM, John R Levine wrote: > >>> So why is DMARC any more useful than these "hacks"? >> >> Good question. As originally intended, DMARC was for mail from >sources where a failure reliably meant phish. Then AOL and Yahoo >repurposed it to push their support costs onto other people, and its >value has been under debate ever since. > >Also a major reason that people who were dubious about SPF policy and >extremely dubious about ADSP supported DMARC was that it has reporting >and dry run functionality. Run it in p=none mode; use the reports to >make sure that nothing breaks; if nothing breaks switch to p=reject. > >I didn't think that anyone significant would skip the testing, >reporting and decision making steps and leap directly to intentionally >breaking email for their users their users' correspondents. I don't think they were confused about the breakage (see Yahoo's original announcement of the change). They knew what would happen and decided it was Okay given the perceived benefit. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On 4/9/15 6:24 AM, Anne Bennett wrote: Hector Santos writes: >> A database is still needed of which domains will have an >> outbound mail stream with two signatures. Some how the list domains >> will still need to register with the Yahoos and tell the Yahoos, >> "Please send us two signatures authorizing out list domain."I >> would like to call this a "registration" problem because thats seems >> to be the area of disagreement as a real problem. > I have to agree; if this is the case, to me, it is a > show-stopper. The genius of the DKIM and SPF and DMARC > approaches is that they are DNS-based, and thus completely > decentralized. The idea that lists would have to register with > the e-mail providers of all of their contributors, or that I > as a (very small!) e-mail provider would have to figure out > what is and isn't a list, doesn't scale. > > I have not yet taken the time to fully understand the "weak and > strong signatures" idea, but if I may be forgiven for commenting > anyway: could the above problem be solved by having "original" > signers always supply various forms of signature (without > needing to figure out if the receiver address is a list), and > having "intermediate" signers (such as mailing lists) add more > signatures as described in the draft? A message that arrives > with only the "original" signatures would be checked against > the strong one, and a message that arrives with "additional" > signatures would be checked as per the draft. > > Of course, if the idea of specifically setting up a third-party > trust is crucial to the proposal, then my suggestion is useless, > and the "registration problem" is not solvable. Dear Anne and Hector, Tag/conditional DKIM expects ESP now offloading support issues onto various third-parties to instead apply extremely limited signatures against all outbound messages while guessing their user's recipient's signing domain in hopes this new signature might satisfy DMARC's From alignment requirement as seen by receivers implementing DMARC. This still ignores Sender header fields claiming to have actually sent the message. ESPs would have less overhead and would handle smaller message sizes by simply ensuring clients see Sender header fields when used as a basis for acceptance. In any case DMARC should be adjusted to assert support for any new alignment or signature mode of operation. Outlook already provides a means to expose the Sender and can be done with rather simple MUA reconfiguration to select displayed headers. TPA-Label in comparison represents both a database established by the DMARC domain to eliminate any additional message overhead while not imposing changes on third-party services. ATPS remains flawed since it also required special DKIM signatures by third-party services to somehow also determine possible DNS label encoding variants employed by a user's domain. In essence, ATPS imposes a database support requirement onto those likely offering a free third-party service while also expecting similar support from ESPs. Tag/conditional DKIM is not really that much better, since it still depends on support from ESP's and fails to offer a better fallback mode when these ESPs fail to act. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On 4/9/2015 2:27 PM, John Levine wrote: A database is still needed of which domains will have an outbound mail stream with two signatures. Sorry, no, that's completely wrong. Please reread the draft. Do you have a reference point, text in the draft related to this to clear it up? How will signers know what domains will have the extra processing, dual signature creation enabled? Does all outbound mail get dual signatures? How will Yahoo know that ietf.org is an "authorized" 3rd party signer in order for yahoo to create two signatures? As you know this will create a major loophole. Your security section admits as much to the security loophole. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On 4/9/2015 10:17 AM, Rolf E. Sonneveld wrote:
On 04/09/2015 03:24 PM, Anne Bennett wrote:
Hector Santos writes:
A database is still needed of which domains will have an
outbound mail stream with two signatures. Some how the list domains
will still need to register with the Yahoos and tell the Yahoos,
"Please send us two signatures authorizing out list domain."I
would like to call this a "registration" problem because thats seems
to be the area of disagreement as a real problem.
I have to agree; if this is the case, to me, it is a
show-stopper. The genius of the DKIM and SPF and DMARC
approaches is that they are DNS-based, and thus completely
decentralized. The idea that lists would have to register with
the e-mail providers of all of their contributors, or that I
as a (very small!) e-mail provider would have to figure out
what is and isn't a list, doesn't scale.
This can be solved by having the owners of mailing lists publish a
yet-to-be-defined DNS record in which they proclaim the presence of a
mailing list within that domain. I'm contemplating to write a draft
for this, as more than one of the suggested solutions to the mailing
list problem might benefit from this.
Its either going to be a internal database or a public database, and
with internal, we begin to have targeted sites (those without a database).
Having said that, I don't like the idea of designing all sorts of
auxilliary technologies to solve the problems introduced by DMARC, or
better said: if we'd come up with such helper technologies we should
try to address as many use cases, presented in [1], as possible. If we
do not, at the the end of the day we'll have created a myriad of new
technologies, considerably increased the complexity of the e-mail
ecosystem worldwide with a net result of zero as long as senders still
treat p=reject as p=none/quarantine.
/rolf
[1] https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-01.txt
+1
Following john's example, he wishes for "taugh.com" to authorize
"ietf.org" as a 3rd party signer. Using ATPS, he would create a DNS
record:
base32(sha1("ietf.com"))._atps.taugh.com
This would be it. The receiver will just check for this ATPS record.
The only reason for the base32(sha1()) hashed subdomain was because
there was a domain name length concern or some possible INTL character
concern, as I recall. But I am not sure we need it, it would
certainly remove API complexity when the record is simplified to:
ietf.org._atps.taugh.com
In any case, this would be it. The receivers will see:
From: jo...@taugh.com
To: dmarc@ietf.org
DKIM-Signature: ...; d=ietf.org; ... new good strong 3rd party
signature
This provides the two variables for the DMARC+ATPS lookup:
POLICY = DKIM_DMARC_ATPS(ADID, SDID)
We can't be using a DNS lookup as a reason for not using ATPS and
continue to investigate these alternatives which have even higher
overhead. In DMARC+ATPS, you would have 1 additional DNS lookup.
With the @FS=1 lookup ideas, you also have 1 additional signature key
lookup.
I agree that the "database" is the key issue here. But the above
Protocol model is the same with a blackbox functionality where we have
known inputs (ADID, SDID) and known outputs (ACCEPT, REJECT,
QUARANTINE, DISCARD) we want to have. There are boundary limits here.
All possible input and actions are known, including doing nothing.
PS: This is what we have for our authorized signers under my isdg.net
zone:
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;" )
Is it really a DNS concern these days if a textual zone file has 30k
or 50K subdomain records? Is it a limit due to their text editor?
I'm sure a GUI will help, but the text guys are still going to popup
their editor too. Is that still a problem today? I don't think so.
New tools can be written to automatic the process.This should
not be a DNS or Configuration/Setup limitation issue.
--
HLS
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
>This can be solved by having the owners of mailing lists publish a >yet-to-be-defined DNS record in which they proclaim the presence of a >mailing list within that domain. That's unlikely to work, because malicious people can publish anything that legitimate lists can. There's a fundamental rule that anything you publish about yourself can only decrease other people's opinion of mail that appears to be from you, not increase it. DMARC, for example, is all about saying mail that appears to be from you actually isn't. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
>> A database is still needed of which domains will have an >> outbound mail stream with two signatures. Sorry, no, that's completely wrong. Please reread the draft. >I have not yet taken the time to fully understand the "weak and >strong signatures" idea, but if I may be forgiven for commenting >anyway: could the above problem be solved by having "original" >signers always supply various forms of signature (without >needing to figure out if the receiver address is a list), and >having "intermediate" signers (such as mailing lists) add more >signatures as described in the draft? No, the problem is that the intermediate signer has changed the message in a way that breaks normal signatures. You wouldn't want to accept a weak signature on its own, since then any malicious third party could have rewritten the messsage, not just the intended recipient. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
>That last sentence is basically what I said about both of my drafts, and >that logic was shot down. Once you've decided you don't like the arbitrary >changes, you know who to blame, but you still have to decide what you like >and what you don't. Yeah, now that I look at your drafts again, I see that we are both making the same assertion that this message is a mutated version of one that someone else sent. I still like mine better because trying to enumerate all of the possible kinds of changes doesn't work very well, e.g., subject tags and per-recipient S/MIME encryption. (Sympa can do the latter.) >"might be mailing lists" sounds like a place for heuristics. How would you >identify an address that might be a list, or content that's likely destined >for a list? The "-l" suffix isn't that common these days. Looking at my DMARC reports from Gmail, the tags suggest they have a pretty good idea of where the lists are. It doesn't have to be perfect, just avoid sending the weak signature to recipients who are likely to be malicious. Re other notes, there's no need to define what a "weak" signature is, since the conditional signature is an ordinary DKIM signature that is verified in the usual way, give or take the new @fs tag. It's up to the original signer how much latitude it wants to give forwarders. R's, John PS: for @ vs !, I think the bike shed would look great in a dusky rose with mocha-taupe trim. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On 04/09/2015 04:51 PM, MH Michael Hammer (5304) wrote: -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Rolf E. Sonneveld Sent: Thursday, April 09, 2015 10:17 AM To: Anne Bennett; dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft On 04/09/2015 03:24 PM, Anne Bennett wrote: Hector Santos writes: A database is still needed of which domains will have an outbound mail stream with two signatures. Some how the list domains will still need to register with the Yahoos and tell the Yahoos, "Please send us two signatures authorizing out list domain."I would like to call this a "registration" problem because thats seems to be the area of disagreement as a real problem. I have to agree; if this is the case, to me, it is a show-stopper. The genius of the DKIM and SPF and DMARC approaches is that they are DNS-based, and thus completely decentralized. The idea that lists would have to register with the e-mail providers of all of their contributors, or that I as a (very small!) e-mail provider would have to figure out what is and isn't a list, doesn't scale. This can be solved by having the owners of mailing lists publish a yet-to-be- defined DNS record in which they proclaim the presence of a mailing list within that domain. I'm contemplating to write a draft for this, as more than one of the suggested solutions to the mailing list problem might benefit from this. How does this solve anything? At least it could help in discovering what domains potentially houses a mailing list. Whether to trust this assertion is something different. I can imagine ESPs could combine this information with information they already have about mailing lists (Yahoo once claimed there were only 30,000 of them, so one way or another they already had some list of mailing lists?). What prevents non-owners of mailing lists proclaiming the presence of a mailing list within "that" domain? What prevents malicious individuals setting up a mailing list and proclaiming it? Nothing at all. But the same holds true for registering with the e-mail providers. Actually, publishing a DNS record might be seen as a submission for registration with the sender. The sending domain still determines whether to accept that registration (and use @fs=domain) or not. Having said that, I don't like the idea of designing all sorts of auxilliary technologies to solve the problems introduced by DMARC, or better said: if we'd come up with such helper technologies we should try to address as many use cases, presented in [1], as possible. If we do not, at the the end of the day we'll have created a myriad of new technologies, considerably increased the complexity of the e-mail ecosystem worldwide with a net result of zero as long as senders still treat p=reject as p=none/quarantine. You will never avoid "local policy" - that is reality. As an aside, don't you mean " as long as VALIDATORS still treat p=reject as p=none/quarantine." Yes, sorry, you're right: that should be 'validators'. /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
> -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Rolf E. > Sonneveld > Sent: Thursday, April 09, 2015 10:17 AM > To: Anne Bennett; dmarc@ietf.org > Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft > > On 04/09/2015 03:24 PM, Anne Bennett wrote: > > Hector Santos writes: > > > >> A database is still needed of which domains will have an outbound > >> mail stream with two signatures. Some how the list domains will > >> still need to register with the Yahoos and tell the Yahoos, > >> "Please send us two signatures authorizing out list domain."I > >> would like to call this a "registration" problem because thats seems > >> to be the area of disagreement as a real problem. > > I have to agree; if this is the case, to me, it is a show-stopper. > > The genius of the DKIM and SPF and DMARC approaches is that they are > > DNS-based, and thus completely decentralized. The idea that lists > > would have to register with the e-mail providers of all of their > > contributors, or that I as a (very small!) e-mail provider would have > > to figure out what is and isn't a list, doesn't scale. > > This can be solved by having the owners of mailing lists publish a yet-to-be- > defined DNS record in which they proclaim the presence of a mailing list > within that domain. I'm contemplating to write a draft for this, as more than > one of the suggested solutions to the mailing list problem might benefit > from this. > How does this solve anything? What prevents non-owners of mailing lists proclaiming the presence of a mailing list within "that" domain? What prevents malicious individuals setting up a mailing list and proclaiming it? > Having said that, I don't like the idea of designing all sorts of auxilliary > technologies to solve the problems introduced by DMARC, or better said: if > we'd come up with such helper technologies we should try to address as > many use cases, presented in [1], as possible. If we do not, at the the end of > the day we'll have created a myriad of new technologies, considerably > increased the complexity of the e-mail ecosystem worldwide with a net > result of zero as long as senders still treat p=reject as p=none/quarantine. > You will never avoid "local policy" - that is reality. As an aside, don't you mean " as long as VALIDATORS still treat p=reject as p=none/quarantine." ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On 04/09/2015 03:24 PM, Anne Bennett wrote: Hector Santos writes: A database is still needed of which domains will have an outbound mail stream with two signatures. Some how the list domains will still need to register with the Yahoos and tell the Yahoos, "Please send us two signatures authorizing out list domain."I would like to call this a "registration" problem because thats seems to be the area of disagreement as a real problem. I have to agree; if this is the case, to me, it is a show-stopper. The genius of the DKIM and SPF and DMARC approaches is that they are DNS-based, and thus completely decentralized. The idea that lists would have to register with the e-mail providers of all of their contributors, or that I as a (very small!) e-mail provider would have to figure out what is and isn't a list, doesn't scale. This can be solved by having the owners of mailing lists publish a yet-to-be-defined DNS record in which they proclaim the presence of a mailing list within that domain. I'm contemplating to write a draft for this, as more than one of the suggested solutions to the mailing list problem might benefit from this. Having said that, I don't like the idea of designing all sorts of auxilliary technologies to solve the problems introduced by DMARC, or better said: if we'd come up with such helper technologies we should try to address as many use cases, presented in [1], as possible. If we do not, at the the end of the day we'll have created a myriad of new technologies, considerably increased the complexity of the e-mail ecosystem worldwide with a net result of zero as long as senders still treat p=reject as p=none/quarantine. /rolf [1] https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-01.txt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
Hector Santos writes: > A database is still needed of which domains will have an > outbound mail stream with two signatures. Some how the list domains > will still need to register with the Yahoos and tell the Yahoos, > "Please send us two signatures authorizing out list domain."I > would like to call this a "registration" problem because thats seems > to be the area of disagreement as a real problem. I have to agree; if this is the case, to me, it is a show-stopper. The genius of the DKIM and SPF and DMARC approaches is that they are DNS-based, and thus completely decentralized. The idea that lists would have to register with the e-mail providers of all of their contributors, or that I as a (very small!) e-mail provider would have to figure out what is and isn't a list, doesn't scale. I have not yet taken the time to fully understand the "weak and strong signatures" idea, but if I may be forgiven for commenting anyway: could the above problem be solved by having "original" signers always supply various forms of signature (without needing to figure out if the receiver address is a list), and having "intermediate" signers (such as mailing lists) add more signatures as described in the draft? A message that arrives with only the "original" signatures would be checked against the strong one, and a message that arrives with "additional" signatures would be checked as per the draft. Of course, if the idea of specifically setting up a third-party trust is crucial to the proposal, then my suggestion is useless, and the "registration problem" is not solvable. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Wed, Apr 8, 2015 at 7:06 PM, John Levine wrote: > It seems to me that this addresses the same issues that the list > mutation stuff does with a lot less complication, and without having > to enumerate all of the ways that a list might change the message. It > only assumes that the list won't change To, From, Date, or Message-ID, > which matches my list experience. The list can make arbitrary changes > to the message body, but if it does, you know who to blame. > That last sentence is basically what I said about both of my drafts, and that logic was shot down. Once you've decided you don't like the arbitrary changes, you know who to blame, but you still have to decide what you like and what you don't. > As a lazy list operator, I also like the fact that it doesn't require > lists to do anything different from what they should be doing now, > sign their outgoing mail. Senders put additional weak signatures on > mail sent to addresses that might be mailing lists, verifiers have to > upgrade to understand new signatures. Note that smelling like a > mailing list is not the same as whitelisting mailing lists. > "might be mailing lists" sounds like a place for heuristics. How would you identify an address that might be a list, or content that's likely destined for a list? The "-l" suffix isn't that common these days. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
Fairly simple? I'm not sure about that. 1) The signer engine needs to do two signatures now. This will be a major code change, more outbound signing overhead. There is still that so called scalability, "big data" problem. How will the "YAHOOs" scale this? A database is still needed of which domains will have an outbound mail stream with two signatures. Some how the list domains will still need to register with the Yahoos and tell the Yahoos, "Please send us two signatures authorizing out list domain."I would like to call this a "registration" problem because thats seems to be the area of disagreement as a real problem. 2) Two (actually all) receivers now have to comply; the MLM MDA receiver (middle ware) and the final User MDA receivers. All middle ware MUST NOT strip the weak 1st party signature. All this is not fairly simple changes. The idea has the same end result for 3rd party authorization with more complex calculations at all points; signers, middle ware and receivers. This is far more complex than a simple DNS lookup of the ADID/SDID at the receivers satisfying the same end result question -- "Does the ADID authorize the SDID as a signer?" Are we trying to skip the DNS part from the solution of all this? I would like to ask the chairs, if the Indirect Mail Interop report including further explorations into ATPS and TPA, then why is that not happening, and who will do it? Obviously, Murray is showing his disinterest in completing the DKIM ATPS work. The IETF should present all the solutions in this complicated project. Compared to what being proposed with this idea and Murray's other two ideas, the DNS lookup method is still a viable option, if only, to be included in the total solution pack: DKIM+DMARC+ATPS as a faster, optimized, least change approach, more proven in the market place with APIs already set to do the ADID lookup. DKIM+DMARC "In-band" method, such as Levine's @FS= idea for, I guess, for the customers out there that, for some reason, want a more complex DKIM engine in signing and verifying in order to do the same thing, perhaps because they have problems interacting with their DNS administration requirements? Even if this dual signature @FS= approach goes forward, the software change requirements will allow for an optimized DNS authorization lookup method to be included. -- HLS On 4/9/2015 12:52 AM, Murray S. Kucherawy wrote: On Wed, Apr 8, 2015 at 7:06 PM, John Levine wrote: I updated my conditional signature draft, which is now (thanks to a suggestion from Ned Freed) the mandatory tag draft. https://tools.ietf.org/html/draft-levine-dkim-conditional-01 [...] Well, I'm game to try. Adjustments to the parsing engine should be fairly simple, and a couple of extra steps to notice and resolve the forward reference will be needed. And maybe some extra return codes. I'd use "!" instead of "@", I think, as an indication of their importance when observed visually, but that's rather a minor point. The first thing that hits me: Do we have to be specific about what's meant by "weak"? How does the verifier decide if it's "weak enough" or perhaps "too weak"? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
