On 6/2/2020 8:45 PM, Douglas E. Foster wrote:
Someone said that the Sender Address is all we can trust. Nonsense.
+1
As to identifiers: The RFC 5321 MAILFROM sender is intended, at least
in my understanding, to represent the login account used to create the
message, while the RFC 5322 From H
I have to ask these engineering questions because we spent a lot of
time developing this functional specifications.
How much does DMARC follow the DKIM Signing Policy functional specs?
Requirements for a DKIM Signing Practices Protocol
https://tools.ietf.org/html/rfc5016
In addition, is DMARC
On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote:
> On 6/3/2020 10:20 AM, Alessandro Vesely wrote:
>> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote:
>>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
MUAs should be discouraged from displaying or using Author:, unless
(verifiably
On 6/3/2020 10:20 AM, Alessandro Vesely wrote:
On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote:
On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
MUAs should be discouraged from displaying or using Author:, unless
(verifiably) signed by a trusted domain or otherwise configured by the user.
Wh
On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote:
> On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
>> MUAs should be discouraged from displaying or using Author:, unless
>> (verifiably) signed by a trusted domain or otherwise configured by the user.
>
> Why?
That avoids the dreaded back-to-sq
On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
MUAs should be discouraged from displaying or using Author:, unless
(verifiably) signed by a trusted domain or otherwise configured by the user.
Why?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
On Tue 02/Jun/2020 19:00:55 +0200 Dave Crocker wrote:
> On 6/2/2020 9:44 AM, Jesse Thompson wrote:
>> I'm relaying these DMARC questions/concerns on behalf of an email admin at
>> another university. [...]
>>
>> "
>> I don't see on the list of issues the most fundamental problem of DMARC,
>> namel
