On 1/16/2019 11:18 AM, John Levine wrote:
> Remember, that if your software rewrites an invalid record into a
> correct one, you are trying to read the mind of the person who wrote
> the misformed record.
To emphasize a point you made earlier: There are many, small
adjustments that a receiver might make, with the intention of operating
more robustly. The current examples certainly quality as small and
seemingly innocuous. But the earlier point was that one deviation from
the specification bodes ill for more important questions of conformance...
If they didn't read this part carefully, why believe they read other
parts more carefully?
The seemingly innocuous nature of the accomodation is only one of several
factors that need to be considered when deciding whether or not to implement
these things. Others include, but are not limited to:
(0) What are the worst case security considerations?
(1) Whether or not the misbehavior is widespread.
(2) Is the misbehavior likely to be corrected if you don't accomodate it?
(3) What wiil the effect of telling customers experiencing difficulties that
it's Someone Else's Problem be?
(4) What is the long term impact on your code going to be?
All that said, in the present case this appears to be a nobrainer: Since the
correct behavior is to ignore malformed records, the security implications may
be significant, it is not widespread behavior, it's very likely to be
corrected, telling people that banks should get their security right seems like
an easy argument to make, and it's a bit of a wart on the code.
I'll also note that transmitters as well as receivers can play the
accomodatation game, with similar effects: What should be common cases
get turned into corner cases, and interoperability suffers as a result.
Ned
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
