Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/22/2015 11:44 PM, Stephen J. Turnbull wrote: Franck Martin writes: > > From: "Stephen J. Turnbull" > > (3) I would really like to see some provision for reporting to mailbox > > users when their mail is being discarded > The email is bounced, not discarded. Not necessarily.

Re: [dmarc-ietf] DMARC ATPS Interop Note

Franck Martin writes: > > From: "Stephen J. Turnbull" > > (3) I would really like to see some provision for reporting to mailbox > > users when their mail is being discarded > The email is bounced, not discarded. Not necessarily. Discard is one of the standard interpretations of "rejec

Re: [dmarc-ietf] DMARC ATPS Interop Note

Except of course for all of the people who don't look at all the crud in their spam folder. They're not likely to write about messages they don't see. If it's in the spam folder, for a whole lot of people it might as well be discarded. If a tree falls in the forest and your don't hear it, does

Re: [dmarc-ietf] DMARC ATPS Interop Note

- Original Message - > From: "John R Levine" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Friday, May 22, 2015 5:08:03 PM > Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note > > > This is of course if the message is not spammy or c

Re: [dmarc-ietf] DMARC ATPS Interop Note

This is of course if the message is not spammy or contain a virus, or nasty stuff like that, where the anti-spam filter may discard the message. Except of course for all of the people who don't look at all the crud in their spam folder. They're not likely to write about messages they don't s

Re: [dmarc-ietf] DMARC ATPS Interop Note

- Original Message - > From: "John Levine" > To: dmarc@ietf.org > Cc: fra...@peachymango.org > Sent: Friday, May 22, 2015 4:17:33 PM > Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note > > >> (3) I would really like to see some provision for reporting

Re: [dmarc-ietf] DMARC ATPS Interop Note

>> (3) I would really like to see some provision for reporting to mailbox >> users when their mail is being discarded due to publication of >> p=reject by their mailbox providers, especially in cases where a >> Mediator is willing to put its reputation on the line by signing >> the

Re: [dmarc-ietf] DMARC ATPS Interop Note

- Original Message - > From: "Stephen J. Turnbull" > To: "Murray S. Kucherawy" > Cc: dmarc@ietf.org, "Douglas Otis" > Sent: Thursday, May 14, 2015 12:51:44 AM > Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note > > Murray S. Kuch

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull wrote: > > What gets added from here forward really needs to be as innocuous > > as possible. I believe we're in a position where things like SPF > > and DKIM are still young enough that their implementations are > > malleable, > > I'm no

Re: [dmarc-ietf] DMARC ATPS Interop Note

Murray S. Kucherawy writes: > What gets added from here forward really needs to be as innocuous > as possible. I believe we're in a position where things like SPF > and DKIM are still young enough that their implementations are > malleable, I'm not sure what you mean. Now that I actually kn

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Wed, May 13, 2015 at 9:05 PM, Stephen J. Turnbull wrote: > > Currently ALL DMARC policy assertions ignore the role of the > > Sender header field. > > Which seems theoretically correct to me, as (unlike From) Sender is > not arguably a field reserved to Author Domains. Of course a Mediator

Re: [dmarc-ietf] DMARC ATPS Interop Note

Douglas Otis writes: > Dear Stephen, > > Perhaps my intent was obscured by thoughts of what's next. > Of course, nothing prevents DKIM/SPF alignment with the > Sender header field. Restating: If it's signed by upstream and altered as RFC 5322 suggests it should be for mail which is receive

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/12/15 6:58 PM, Stephen J. Turnbull wrote: > Douglas Otis writes: > > > DMARC being unable to assert the domain > > I'm not sure what you mean by "assert the domain". AFAICS no new > protocol is needed to validate Sender -- SPF and DKIM allow that > already, and it's not obvious to me where

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/12/15 6:58 PM, Stephen J. Turnbull wrote: > Douglas Otis writes: > > > DMARC being unable to assert the domain > > I'm not sure what you mean by "assert the domain". AFAICS no new > protocol is needed to validate Sender -- SPF and DKIM allow that > already, and it's not obvious to me where

Re: [dmarc-ietf] DMARC ATPS Interop Note

Douglas Otis writes: > DMARC being unable to assert the domain I'm not sure what you mean by "assert the domain". AFAICS no new protocol is needed to validate Sender -- SPF and DKIM allow that already, and it's not obvious to me where the big threat is from a misaligned or spoofed Sender. (A B

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/11/15 10:28 PM, Hector Santos wrote: > On 5/11/2015 2:56 PM, Douglas Otis wrote: >> >> On 5/10/15 10:08 PM, Murray S. Kucherawy wrote: >>> On Sun, May 10, 2015 at 4:37 PM, Douglas Otis >>> wrote: ATPS included an onerous task for any third-party service likely used on a gratis bas

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/12/2015 1:18 AM, Scott Kitterman wrote: On Tuesday, May 12, 2015 12:16:19 AM Hector Santos wrote: On 5/11/2015 10:17 PM, Stephen J. Turnbull wrote: Scott Kitterman writes: > Actually, the idea behind MARID was to come up with a single > solution Is there something we can learn from

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/11/2015 2:56 PM, Douglas Otis wrote: On 5/10/15 10:08 PM, Murray S. Kucherawy wrote: On Sun, May 10, 2015 at 4:37 PM, Douglas Otis wrote: ATPS included an onerous task for any third-party service likely used on a gratis basis. Each third-party was expected to learn specific hash algorit

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Tuesday, May 12, 2015 12:16:19 AM Hector Santos wrote: > On 5/11/2015 10:17 PM, Stephen J. Turnbull wrote: > > Scott Kitterman writes: > > > Actually, the idea behind MARID was to come up with a single > > > solution > > > > Is there something we can learn from MARID? I don't see it in the

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/11/2015 10:33 PM, Scott Kitterman wrote: On Tuesday, May 12, 2015 11:17:08 AM Stephen J. Turnbull wrote: Scott Kitterman writes: > Actually, the idea behind MARID was to come up with a single > solution Is there something we can learn from MARID? I don't see it in the context of the c

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/11/2015 10:17 PM, Stephen J. Turnbull wrote: Scott Kitterman writes: > Actually, the idea behind MARID was to come up with a single > solution Is there something we can learn from MARID? I don't see it in the context of the current discussion, as MARID had little to say about third pa

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Tuesday, May 12, 2015 11:17:08 AM Stephen J. Turnbull wrote: > Scott Kitterman writes: > > Actually, the idea behind MARID was to come up with a single > > solution > > Is there something we can learn from MARID? I don't see it in the > context of the current discussion, as MARID had little

Re: [dmarc-ietf] DMARC ATPS Interop Note

Scott Kitterman writes: > Actually, the idea behind MARID was to come up with a single > solution Is there something we can learn from MARID? I don't see it in the context of the current discussion, as MARID had little to say about third parties (it treated them as first parties, and handled t

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/10/15 10:08 PM, Murray S. Kucherawy wrote: > On Sun, May 10, 2015 at 4:37 PM, Douglas Otis wrote: > >> ATPS included an onerous task for any third-party service >> likely used on a gratis basis. Each third-party was expected >> to learn specific hash algorithms of each From domain. A >> di

Re: [dmarc-ietf] DMARC ATPS Interop Note

Murray, a clarification about DSAP. Of late, I've been using the term DSAP as a general methodology for a complete DKIM Signature Authorization Protocol. DSAP, TPA, ATPS are all the basic ideas. We need a generic term since there are many with all the same basic functional principles, but in

Re: [dmarc-ietf] DMARC ATPS Interop Note

I don't think it correct to be implying "we gave it an old college try" when in fact, everything was being done to kill policy ideas. Murray, Crocker and Levine where the key IETF cogs working on the DKIM project and all three were pushing a Trust Model, removing the author domain from the pic

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sun, May 10, 2015 at 4:37 PM, Douglas Otis wrote: > ATPS included an onerous task for any third-party service > likely used on a gratis basis. Each third-party was expected > to learn specific hash algorithms of each From domain. A > difficult process on top of changing their structure of DKI

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/10/15 11:00 AM, Murray S. Kucherawy wrote: > Sorry, I sent that too quickly. A couple of other points: > > In both schemes, you need a "registry", which is the set A as maintained by > B through whatever means B wishes. Any DNS mechanism, however, requires > that all mail flows from B via

Re: [dmarc-ietf] DMARC ATPS Interop Note

> On May 10, 2015, at 2:00 PM, Murray S. Kucherawy wrote: > >> On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy >> wrote: >> That is, for a registration scheme, you might be testing for the existence >> of a DNS record called A._related._dmarc.B. For a re-signing scheme, you're >> loo

Re: [dmarc-ietf] DMARC ATPS Interop Note

Scott Kitterman writes: > I don't have any particular insight. I do think that the group > ought to be paying close attention to those who do. What is the sound of a closed mouth speaking? > As I attempted to communicate in my assessment framework proposal, > whatever solution the group coal

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy wrote: > That is, for a registration scheme, you might be testing for the existence > of a DNS record called A._related._dmarc.B. For a re-signing scheme, > you're looking for a signature from A that is somehow endorsed (for some > definition

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sun, May 10, 2015 at 10:40 AM, Stephen J. Turnbull wrote: > > This "How do we populate the set?" is "the registration problem". > > There are some implicit "safely" and "at scale" adverbs in there > > too, just for flavor. > > Sure, but even with the adverbs it's not a "problem" for per-mes

Re: [dmarc-ietf] DMARC ATPS Interop Note

Murray S. Kucherawy writes: > That means any actor inside "A" can sign mail that claims to come > from "B". So if "A" is compromised, "B" is hosed. The "B"s of the > world tend not to be so thrilled with this. I think only Hector and Douglas would argue with you, and I predict they will. Le

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sun, May 10, 2015 at 7:05 AM, Anne Bennett wrote: > But I think that some of the "re-signing" schemes being proposed at > the moment do *not* require this type of registration, so in those > cases, the registration problem wouldn't apply. If A is not "signing > B's mail", but rather, "signing

Re: [dmarc-ietf] DMARC ATPS Interop Note

Anne Bennett writes: > >> But if I understand correctly, it's being suggested that for > >> various proposals made here to work, either the sender's mail > >> system or the final receiver's mail system would have to become > >> aware of all "All" has been asserted. Why it needs to be "all" h

Re: [dmarc-ietf] DMARC ATPS Interop Note

On May 10, 2015 11:55:22 AM EDT, "Stephen J. Turnbull" wrote: >Scott Kitterman writes: > > > Yahoo, for example, already consider the impact of this and other > > breakage to be less than the benefit of p=reject. > >True, but the benefit of p=reject is huge: Yahoo! claims malicious >mailflows of

Re: [dmarc-ietf] DMARC ATPS Interop Note

Scott Kitterman writes: > Yahoo, for example, already consider the impact of this and other > breakage to be less than the benefit of p=reject. True, but the benefit of p=reject is huge: Yahoo! claims malicious mailflows of more than a million messages per minute disappeared like magic when the

Re: [dmarc-ietf] DMARC ATPS Interop Note

The registration problem is not a red herring because it doesn't exist, but because it is intractable. Thus, any response to the third-party problem that relies on a solution to that problem (which includes ATPS, DSAP, and TPA) is probably not viable. I agree. But I think that some of the "re-

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/9/2015 3:01 PM, Scott Kitterman wrote: On May 9, 2015 1:13:15 PM EDT, Hector Santos wrote: Your bar is too unrealistically high for typical IETF project work that is still in the experimental stages. You should be thankful, we didn't apply this bar to the SPF experiment. It wasn't brou

Re: [dmarc-ietf] DMARC ATPS Interop Note

Murray, >> I think that the "registration problem" is a red >> herring after all. There's no deterministic way to decide what's a >> legitimate mailing list (or other re-signer), any more than there's any >> way to deterministically decide what's a legitimate originator. Those >> determinations

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/10/2015 2:14 AM, Murray S. Kucherawy wrote: On Sat, May 9, 2015 at 10:33 PM, Anne Bennett mailto:a...@encs.concordia.ca>> wrote: Hmm, Hector, I think you've forced me to convince myself that you're on the right track: I think that the "registration problem" is a red herring afte

Re: [dmarc-ietf] DMARC ATPS Interop Note

es ATPS, DSAP, and TPA) is probably not viable. +1. -- Terry From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Saturday, May 9, 2015 11:14 PM To: Anne Bennett Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note On Sat, May 9, 2015 at 10:33 PM

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sat, May 9, 2015 at 10:33 PM, Anne Bennett wrote: > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or ot

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sat, May 9, 2015 at 10:33 PM, Anne Bennett wrote: > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or ot

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sunday, May 10, 2015 01:33:48 AM Anne Bennett wrote: > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or o

Re: [dmarc-ietf] DMARC ATPS Interop Note

Hector, >> Now of course we all know that if I used "!all" in my SPF >> record, this would break messages from my users who: > > Do you mean "-ALL" hardfail policy? Yes, sorry. >>1 - ... are currently offsite but set their From: line to >>my domain, then submit mail through another

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/9/15 8:07 AM, Murray S. Kucherawy wrote: > On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull > wrote: > >> > Agreed again. And as Terry has said and I think we can infer about >> > other large operators, it's incorrect to assume (and plain wrong to >> > assert) that this is an easy pr

Re: [dmarc-ietf] DMARC ATPS Interop Note

this as an example. -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos Sent: Saturday, May 9, 2015 10:13 AM To: dmarc@ietf.org Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note Your bar is too unrealistically high for typical IETF

Re: [dmarc-ietf] DMARC ATPS Interop Note

On May 9, 2015 1:13:15 PM EDT, Hector Santos wrote: >Your bar is too unrealistically high for typical IETF project work that >is still in the experimental stages. You should be thankful, we >didn't apply this bar to the SPF experiment. It wasn't brought to be the IETF until it had substantial d

Re: [dmarc-ietf] DMARC ATPS Interop Note

On May 9, 2015 1:09:09 PM EDT, "Stephen J. Turnbull" wrote: >Scott Kitterman writes: > > > How many solutions do you think operators will be willing to > > implement? > >As many as have an expected benefit/cost ratio greater than 1, of >course. > >If you want numbers, my expectation is about 0.5 (

Re: [dmarc-ietf] DMARC ATPS Interop Note

DNS zones. -- Terry [1] I don't know exactly how many domains we have, I just picked this as an example. -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos Sent: Saturday, May 9, 2015 10:13 AM To: dmarc@ietf.org Cc: dmarc@ietf.org Subjec

Re: [dmarc-ietf] DMARC ATPS Interop Note

Murray S. Kucherawy writes: > I'm having trouble coming up with a heuristic that is even certain > to grab "most" of them. Without definitions of "certain", "'most'", and "them", how is anybody supposed to meet such a requirement? Pending receipt of such definitions, I'll go see if I can get s

Re: [dmarc-ietf] DMARC ATPS Interop Note

Your bar is too unrealistically high for typical IETF project work that is still in the experimental stages. You should be thankful, we didn't apply this bar to the SPF experiment. -- Hector Santos http://www.santronics.com > On May 9, 2015, at 10:09 AM, Scott Kitterman wrote: > >> On May 9

Re: [dmarc-ietf] DMARC ATPS Interop Note

Heuristics for this are quite simple to generate. But it needs verification, confirmation, authorization before it can be automated. That is what makes it a heuristic and doesn't belong in the SMTP transport where this protocol can be implemented if only from a delayed learning concept, i.e. s

Re: [dmarc-ietf] DMARC ATPS Interop Note

Scott Kitterman writes: > How many solutions do you think operators will be willing to > implement? As many as have an expected benefit/cost ratio greater than 1, of course. If you want numbers, my expectation is about 0.5 (the odds are perceptibly better than even that *nothing* will be done)

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull wrote: > > Agreed again. And as Terry has said and I think we can infer about > > other large operators, it's incorrect to assume (and plain wrong to > > assert) that this is an easy problem for them to solve in a > > reliable way. > > Plea

Re: [dmarc-ietf] DMARC ATPS Interop Note

On May 9, 2015 5:00:24 AM EDT, "Stephen J. Turnbull" wrote: >Murray S. Kucherawy writes: > > > Agreed again. And as Terry has said and I think we can infer about > > other large operators, it's incorrect to assume (and plain wrong to > > assert) that this is an easy problem for them to solve in a

Re: [dmarc-ietf] DMARC ATPS Interop Note

Murray S. Kucherawy writes: > Agreed again. And as Terry has said and I think we can infer about > other large operators, it's incorrect to assume (and plain wrong to > assert) that this is an easy problem for them to solve in a > reliable way. Please define "reliable." I gather you all thi

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/8/2015 8:19 PM, Murray S. Kucherawy wrote: Punting on this as an "implementation issue" leaves a pretty substantial hole in whatever gets rolled out. To me it's like buying a car with a completely absent steering mechanism, and you have to do the research to figure out which one fits and w

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/8/15 5:19 PM, Murray S. Kucherawy wrote: > On Fri, May 8, 2015 at 10:29 AM, Anne Bennett > wrote: >> Murray S. Kucherawy writes (with respect to ATPS if I got this right): > You did. There's still that pesky registration problem to address. >> Hector Santos writes: >> >> [...] >> >> The

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Fri, May 8, 2015 at 10:29 AM, Anne Bennett wrote: > > Murray S. Kucherawy writes (with respect to ATPS if I got this right): > You did. > >> There's still that pesky registration problem to address. > > Hector Santos writes: > > [...] > > Therefore, I don't think that SPF has a "registratio

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/8/2015 1:29 PM, Anne Bennett wrote: Murray S. Kucherawy writes (with respect to ATPS if I got this right): There's still that pesky registration problem to address. Hector Santos writes: Separate issue. SPF would not be here if you used this same criteria. None of the big domains yo

Re: [dmarc-ietf] DMARC ATPS Interop Note

Murray S. Kucherawy writes (with respect to ATPS if I got this right): >> There's still that pesky registration problem to address. Hector Santos writes: > Separate issue. SPF would not be here if you used this same criteria. > None of the big domains you are concern about have hard fails fo

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Thu, May 7, 2015 at 4:24 PM, Scott Kitterman wrote: > No, it's OK for DKIM. The trick is d=ietf.org, which doesn't align for > DMARC > purposes. > We're saying the same thing, I think. I'm presuming a post-MLM message with an author domain signature and an MLM domain signature. The aligned

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/7/2015 11:05 PM, Scott Kitterman wrote: On Thursday, May 07, 2015 09:51:43 PM Hector Santos wrote: On 5/7/2015 7:46 PM, Scott Kitterman wrote: ATPS is assigned in the registry {1] as dkim-atps. As stated already, the work predated what Murray did after ATPS rev04. But its good to know t

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Thursday, May 07, 2015 09:48:30 PM Hector Santos wrote: > On 5/7/2015 7:42 PM, Scott Kitterman wrote: > >> In other words, does the AUTH-RES protocol allow it itself to be > >> extended, it is flexible enough? If not, then AUTH-RES will need to > >> be updated again. > > > > A-R is certainly

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Thursday, May 07, 2015 09:51:43 PM Hector Santos wrote: > On 5/7/2015 7:46 PM, Scott Kitterman wrote: > > ATPS is assigned in the registry {1] as dkim-atps. > > As stated already, the work predated what Murray did after ATPS rev04. > > But its good to know that is this is the case and this is

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/7/2015 7:46 PM, Scott Kitterman wrote: ATPS is assigned in the registry {1] as dkim-atps. As stated already, the work predated what Murray did after ATPS rev04. But its good to know that is this is the case and this is yet another good reason to continue with ATPS work. -- HLS

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/7/2015 7:42 PM, Scott Kitterman wrote: In other words, does the AUTH-RES protocol allow it itself to be extended, it is flexible enough? If not, then AUTH-RES will need to be updated again. A-R is certainly extensible, but there are IANA registries that need to be updated. Its not ext

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Thursday, May 07, 2015 04:53:07 PM Hector Santos wrote: > Scott, > > If this is what you are talking about, there should of been an > AUTH-RES line for "atps=", I can understand that valid technical > point, but I don't agree it is absolute. > > First, it is a DMARC extension and long as it i

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Thursday, May 07, 2015 06:03:22 PM Hector Santos wrote: > On 5/7/2015 5:09 PM, Murray S. Kucherawy wrote: > > On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman > > > > wrote: > > I think it's wrong to describe that as a DMARC result. For DMARC > > as specifi

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Thursday, May 07, 2015 02:09:09 PM Murray S. Kucherawy wrote: > On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman > > wrote: > > I think it's wrong to describe that as a DMARC result. For DMARC as > > specified, that's a fail. > > More precisely, for both DKIM and DMARC it's a fail. For DKIM+

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/7/2015 5:09 PM, Murray S. Kucherawy wrote: On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman mailto:skl...@kitterman.com>> wrote: I think it's wrong to describe that as a DMARC result. For DMARC as specified, that's a fail. More precisely, for both DKIM and DMARC it's a fail. For

Re: [dmarc-ietf] DMARC ATPS Interop Note

On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman wrote: > > I think it's wrong to describe that as a DMARC result. For DMARC as > specified, that's a fail. > > More precisely, for both DKIM and DMARC it's a fail. For DKIM+ATPS-04, it's a pass, but DMARC doesn't pay attention to that. I think it

Re: [dmarc-ietf] DMARC ATPS Interop Note

Scott, If this is what you are talking about, there should of been an AUTH-RES line for "atps=", I can understand that valid technical point, but I don't agree it is absolute. First, it is a DMARC extension and long as it is an indicated marker in the DMARC result, then should be ok. Seco

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/7/2015 4:27 PM, Scott Kitterman wrote: On May 7, 2015 3:54:55 PM EDT, Hector Santos wrote: Since 05/2014, I have published DMARC records for several of my domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag extension was added to my records. For example, for my non-corpora

Re: [dmarc-ietf] DMARC ATPS Interop Note

On 5/7/2015 4:27 PM, Scott Kitterman wrote: On May 7, 2015 3:54:55 PM EDT, Hector Santos wrote: Since 05/2014, I have published DMARC records for several of my domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag extension was added to my records. For example, for my non-corpora

Re: [dmarc-ietf] DMARC ATPS Interop Note

On May 7, 2015 3:54:55 PM EDT, Hector Santos wrote: >Since 05/2014, I have published DMARC records for several of my >domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag >extension was added to my records. For example, for my non-corporate, >"play around" domain isdg.net, I hav

[dmarc-ietf] DMARC ATPS Interop Note

Since 05/2014, I have published DMARC records for several of my domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag extension was added to my records. For example, for my non-corporate, "play around" domain isdg.net, I have: "v=DMARC1; p=none; atps=y; rua=mailto:dmarc-...@is