Charles Lindsey wrote:
There is no SHOULD|MUST about what recipients do. At most, it is a matter
of Best Common Practice, which this WG might well choose to incorporate in
a BCP RFC. But what would such a BCP document say?
I agree, but at some point implementators will need to transform the
functional specification into a technical one. i.e. Software logic
with options etc.
It might say that all invalid DISCARDABLE email "SHOULD" be discarded.
It might say that all invalid DISCARDABLE email "SHOULD" be marked as such
and sent on.
Currently the specification says to discard. I personally think it
would rubber against the specs if an implementor added an option:
[X] Do not discard invalid DISCARDABLE mail. Mark it only.
Possible, sure. But IMV go against the specs. At least it would be
enabled by default. However, I can see that for the more ambiguous
ALL policy:
[_] Discard invalid ALL mail.
Here it is off by default and invalid ALL mail is marked only. Here I
think, the intentional ambiguous ALL policy leaves it open ended and
allows for local policy to decide. No problem here.
It might say that invalid DISCARDABLE email "SHOULD" be treated in some
different way if accompanied by a signed A-R record as I have suggested.
It might say that Listadmins "SHOULD" treat mail addressed to their list
just like any other recipient "SHOULD" treat it.
It might say that Listadmins "SHOULD", as a special case, take actions
different from other recipients (whether by adding A-R records, or
something else).
It might (or might not) make special recommendations for other forwarders,
such as acm.org.
None of these possibilities is, a priori, preordained. None of them is
contrary to anything currently on the Standards Track.
I agree with your overall notes, but I do think that the exception is
that there is a clear MUST Discard for invalid discardable mail that
is independent from any anything else. The main reason of course is
that it must cover legacy transactions (mail without any additional
and related DKIM DNA)
All of them are a proper subject of discussion, should this WG decide to
embark on such a BCP (and the misunderstandings repeatedly displayed here
seem to suggest that something of the sort is needed).
IMV, the only issue is that it adds more complexity. IMV, before we
can even come up with an algorithm, we need have some basic framework
that is presumed everyone will follow or rather be consistent. IMV,
unrestricted resigners conflicts with the very notion of what ADSP
attempts to protect again. So there has to be a decision of resigners
SHOULD|MUST follow it. Only then, IMV, can software developers and
operators using scripts, or ACL, can create a consistent framework.
Otherwise we will continue to see these debates and issues come up.
Seriously, I am stuck. For our WCSMTP receiver, I can easily see
where it can be optional. No Sweat. We will support it, but I can see
where lack of support here is not going to break anything other than
not help protect spoofed domains. But not when the mail is for our
WCLISTSERVE and it has (re)signer features. Ignoring the idea that a
domain has ADSP is problematic here. We could go ahead and just
honor ADSP and be the only system that does so. I guess that would
work. Heck, that might even be a marketing advantage! But it would
surely be nice if there was a network "expectation" to play by the
same rules so that domains can be protected at these other systems as
well.
==
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html