On 6/8/2014 5:13 AM, Vlatko Salaj wrote:
i consider my 3rd party alignment support for DMARC
easy to understand, trivial enough to deploy and
useful enough to cover many use cases, so i would
like to move it to IETF as a, probably, independent
RFC.
does anybody here see interest in helping me out
with this procedure? u should have good english skills,
and at least some xp with RFCs.
be free to contact me if u do.
btw, mr. Hector, would u be so kind to include my
version of the proposal on ur test-page at:
http://www.winserver.com/public/wcDMARC/default.wct
my proposal is quite similar to what u call ASL and
if we agree to merge our two proposals together to at
least some degree, i may actually adopt ASL as a
name for new version, but rename it to
Aligned Sender List.
since ur ASL logic and my ASL logic r similar enough
to merge, it could be beneficial to both proposals,
adding some traction to other, more, advanced 3rd
party support, for cases where ASL is insufficient.
also, that may be a start of a working cooperation
for a true, full-fledged 3rd party DMARC standard,
assimilating* ASL or in addition to ASL.
Hi Vlatko,
Overall, the problem is backward compatibility. When we try to extend
an existing protocol, we need to consider the basic implementation
"ignorance" of any new extended logic.
This is why "asl=" and the "atps=" tags are separate from existing
tags. With the proposed idea to extend "adkim=" and "aspf=", it (the
syntax parsing) can fail with existing systems.
Such situations are suppose to be ok for such protocols language;
unknown tags are to be ignored, not a failure, otherwise the whole
extension concept allowed by the specification is a wash. Won't work
well at all. But this is different from attempting to use a syntax
error as an extended logic.
Doing a quick search for "unknown" in the dmarc draft rev4...
5.2 General Record Format
DMARC records follow the extensible "tag-value" syntax for DNS-based
key records defined in DKIM [DKIM]].
Section 16 creates a registry for known DMARC tags and registers the
initial set defined in this memo. Only tags defined in this memo or
in later extensions, and thus added to that registry, are to be
processed; unknown tags MUST be ignored.
...
A DMARC policy record MUST comply with the formal specification found
in Section 5.3 in that the "v" and "p" tags MUST be present and MUST
appear in that order. Unknown tags MUST be ignored. Syntax errors
in the remainder of the record SHOULD be discarded in favor of
default values (if any) or ignored outright.
So in DMARC protocol theory:
o unknown tags MUST be skipped, ignored,
o syntax errors SHOULD be ignored in favor of its defaults.
This is ok software logic, but you have to watch the latter one. In
practice, syntax errors can be a problem. It also has security
implications, i.e. DoS-like attacks, overwhelming you with invalid
syntax processing overhead that the operator is forced to turn off the
DMARC processor.
But extending an existing tag is almost guaranteed to be a parsing
problem to be expected at some processor. It depends on the
sophistication of the implementation, can't assume everyone is using
the same "DMARC library."
Generally for an extension of an existing tag=value, this is where you
would change the v=DMARC1 version number to something else, i.e.
v=dmarc1.1, v=dmarc2, etc.
To provide an example, here is a general outline for simple token base
parser for something like this:
string rec = GetDMARCRecord(Author.Domain)
do while rec has something
string value = GetNextTag(rec,";") // rec has remaining string
string tag = Split(value,"=") // value has remaining string
case lowercase(tag) of
"v" : process_v(value) // check version
"adkim" : process_adkim(value)
"aspf" : process_aspf(value)
"fo" : process_fo(value)
"rua" : process_ruf(value)
"ruf" : process_ruf(value)
"pct" : process_pct(value)
"p" : process_p(value)
....
end case
end do
The process_adkim(value) logic will MOST LIKELY only have the logic
that has been specified in the DMARC draft which is check a value of:
"r"
"s"
and nothing more.
If DMARC developers had envisioned such extended value needs, it would
allowed for such things as your idea. But in general, its not typical
to see this for many reasons, and within the IETF, it will be pointed
out that simple string parsing is better.
On the other hand, one may also suggest that since we are doing this
more and more with this format for many new DNS based single line
command tag-based language applications, maybe we should have a
formal IETF language syntax for such protocols so intelligent advanced
tag-based parsers can be written.
But it would be more complex and since the same functionality can be
accomplished with the advanced reader required anyway, you might was
well just propose a new tag, like:
"adkimx="
Finally, you would need to do feasibility test to make sure there is
no compatibility problem. I have not seen a problem with the various
domains using "atps=y" or "asl=y" yet but who knows if there are some
DMARC sites with software parsers that see the unknown tags and well,
skip the entire record, do nothing in the name of avoid the possible
"DoS" overhead processing attacks. It would be a 'violation' of the
spec but there still needs to be a feasibility test because if most of
the sites are violating the spec in this regard, then we have a
protocol specification implementation "bug" and generally, in cases
like this, we begin to consider "codifying" the actual industry
behavior in the updated DMARC draft to whats actually seen.
- SHOULD|MAY ignore unknown tags
- MAY throw an exception (abort processor)
Then we will get into debates on what it means to throw an exception
and do we need to control it, limit it, track it, report it, block
abusers, etc.
Can we use a different tag for your proposal?
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
