On Fri, Feb 14, 2014 at 1:51 PM, Vlatko Salaj <vlatko.sa...@goodone.tk>wrote:
> > It may not be that ATPS solves any of your problems, but the ATPS > community > > (small as it is) can similarly say that SRS doesn't solve theirs. > > well, i do not have any proposal on how to fix ATPS-induced DKIM > DMARC-alignment fail. it simply seems DMARC and ATPS are mutually > exclusive, as presently defined. maybe ATPS should be revised to account > for > DMARC compatibility. > Are we talking about the same thing? ATPS doesn't induce DKIM failures; it suggests a way to indicate a message signer can be endorsed by an author, saying "treat this signature as if it were my own". That brings an unaligned DKIM signature into alignment, in DMARC terms. I don't see how it can deteriorate things. Rather, its problem is that it's a corner case with limited adoption. > > maybe spec should have a note about incompatibility with ATPS. but that's > it. > > ...but they aren't incompatible. > >> however, stats about DKIM signatures say nothing about DKIM DMARC > alignment, > >> which numbers are probably quite lower. so, even if DKIM is saved, > >> alignments? > > Wouldn't that be visible in the DMARC aggregate reports? > > where? i'm not aware of any publicly released stats, beside those big > numbers > last year. but those were more of an ad, than real statistical data. > Anyone receiving large amounts of mail and generating reports based on them (Yahoo, for example) has enough data to tell you what percentage of DKIM signatures are passing, and what percentage of those are DMARC-aligned. > > My recollection of most of the SPF and IETF community at the time was > that > > SRS didn't get a favorable reaction. > > are you sure that wasn't about microsoft's version of it, later part of > sender id spec? asaik, plain SRS wasn't hated, it was merely a special case > handling and thus less important to SPF. > Yes, I'm sure. And I don't recall there being multiple versions of SRS back then. I could be wrong, but it could also be the case that people only knew about one version. I also don't recall a version of SRS put forward by Microsoft. > my point was that cause SPF was never finished accounting for forwarders, > mainly > of bad blood caused by sender id, it was, unfortunately, broken from the > start. > > and yes, forwarders do introduce quite a bit of grief into email world. > but, its > late to think about that problem now. we can, however, devise workarounds. > The people working on it had a choice: A version of SPF that didn't deal with forwarding (which is what we got), or a version of SPF that did deal with forwarding in a manner the community at the time felt was unpalatable. It appears to have chosen the former, for better or worse. SPF (the document, not so much the protocol) was just revised to change its status from Experimental to Proposed Standard. SRS didn't come up there either; the consensus supported a version that continued not to deal with forwarding directly. let me ask a public question: was there any intention at all by original > DMARC > authors to consider replacing SPF with SenderID, or to use PRA instead of > "from:" header alignment? while controversial in many ways, not everything > in that algorithm was useless. > Including Sender-ID support was considered and discarded, though DMARC is also extensible to include it later if it turns out to be desirable. However, Sender-ID appears to be drifting into history, so we instead went with the algorithm that's there now. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
