Re: [ietf-smtp] broken signatures, was Curious
2020-07-21 20:48:43
On 7/21/2020 5:41 PM, Paul Smith wrote:
On 21/07/2020 21:45, Hector Santos wrote:
Hmm, my view is that the headers should be at least vaguely useful at
the recipient end. That means that OK examples could be:
- an old (non validating) DKIM record
- X-Virus-Scanned: amavisd-new at amsl.com
- X-BeenThere: ietf-smtp(_at_)ietf(_dot_)org
- X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001,
SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
But useless ones could be:
- X-Data: E5-cx76azc4-nr189/4/434-00019lcm
- X-GRID-REF: ...
- X-MA-Instance: ....
- X-PP-Email-transmission-Id: 407b928e-cb6d-11ea-a29f-b875c0aa69dc
(The above are real examples from some recent legitimate messages I've
received)
My point is that at a minimum, if you were to write an MUA, once also
called Mail Reader/Writer, the fields for the Reader layout viewport
would be, in no specific order, Date:, From:, To:, Subject: and you
really don't need anything else.
But at a local MUA level, there are other things as you pointed out.
Your package may be utilizing extra concepts, Status, Multi-Mime, X-*
related stuff, including DKIM.
A lot depends on the mail is storage. It can be prune is all I am
saying and we have been doing it for a long time. Its a fundamental
feature in Wildcat! where the user has the option to "[_] Preserve
Mime." If enabled, then the mail is stored as is, raw RFC5322 format.
If disabled, the minimum required fields are extracted and then some
for supported features. The rest are not stored. The only time a
user really need to Preserve Mime is when the mail is not rendered
locally, but passed to an offline MUA. The offline MUA has to deal
with the display. With the Online MUA, which I suspect is a major
direction, back to a centralized concept, the backend has all the
power to do whatever it needs to do from a display standpoint. It
doesn't all the extra meta headers.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-smtp] broken signatures, was Curious, (continued)
- Re: [ietf-smtp] broken signatures, was Curious, Hector Santos
- Re: [ietf-smtp] broken signatures, was Curious, Alessandro Vesely
- Re: [ietf-smtp] broken signatures, was Curious, John Levine
- Re: [ietf-smtp] broken signatures, was Curious, Michael Richardson
- Re: [ietf-smtp] broken signatures, was Curious, John R Levine
- Re: [ietf-smtp] broken signatures, was Curious, John R Levine
- Re: [ietf-smtp] broken signatures, was Curious,
Hector Santos <=
- Re: [ietf-smtp] broken signatures, was Curious, John C Klensin
- Re: [ietf-smtp] broken signatures, was Curious, John R Levine
- Re: [ietf-smtp] broken signatures, was Curious, Dave Crocker
- Re: [ietf-smtp] broken signatures, was Curious, John C Klensin
- Re: [ietf-smtp] broken signatures, was Curious, Dave Crocker
- Re: [ietf-smtp] broken signatures, was Curious, Pete Resnick
- Re: [ietf-smtp] broken signatures, was Curious, Dave Crocker
- Re: [ietf-smtp] broken signatures, was Curious, Pete Resnick
- Re: [ietf-smtp] Curious, with this now being associated to emailcore, should list name change?, Pete Resnick
- Re: [ietf-smtp] Curious, with this now being associated to emailcore, should list name change?, Pete Resnick
|
|
|