| 4.1.9. Body Length Limit Abuse
|
| ...
|
| If the verifier observes body length limits when present, there is
| the potential that an attacker can make undesired content visible to
| the recipient. The size of the appended content makes little
| difference, because it can simply be a URL reference pointing to the
| actual content. Receiving MUAs can mitigate this threat by, at a
| minimum, identifying the unsigned content in the message.
I suggest a small change to the last sentence:
Receiving MUAs or online mail presentation readers can mitigate
this threat by, at a minimum, identifying the unsigned content
in the message.
With the following addition:
This threat mitigation can assisted with the
RFC2822.Authorization-Result [I-D.kucherawy-sender-auth-header] by
communicating server-side calculated DKIM verification results in
this header. This will allows the MUA (both offline/online) to use
this information to present to end-users.
The difference.
"Receiving MUA" connotates offline or 3rd party components in the mail
framework, OE, TBIRD, Eudora, pick your favorite, either directly or with
offline mail reader 3rd party plug-ins.
The odds are extremely high, the above "mitigation" will begin first with
server side online mail systems, i.e, web mail where the verification
process will be tied or integrated with the server-side DKIM verification
process. This will be the fastest way to offer DKIM benefits to end-users
across the board in a consistent manner.
A good example is us. We have both offline and online "MUAs". We are first
working on the WebMail, ConsoleMail <tm> side. The offline line readers,
and we have 3 of them, will be extended projects down the road and the hope
is we will have some standard "header" (Authorization-Result:) that the
reader can use to extract and resent verification results.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html