> On Jun 14, 2014, at 5:25 AM, Patrick Rauscher wrote:
>
> Hey,
>
> On Fri, 2014-06-13 at 22:35 -0400, Hector Santos wrote:
>>> Perhaps I'm oversimplifying, but it has seemed self-evident that you need a
>>> single identifier that is displayed to the end user and 5322.From is the
>>> only
>>
Hey,
On Fri, 2014-06-13 at 22:35 -0400, Hector Santos wrote:
> > Perhaps I'm oversimplifying, but it has seemed self-evident that you need a
> > single identifier that is displayed to the end user and 5322.From is the
> > only
> > identifier that even comes close to being the right one.
(I don
> On Jun 9, 2014, at 11:17 PM, Scott Kitterman wrote:
>
> Perhaps I'm oversimplifying, but it has seemed self-evident that you need a
> single identifier that is displayed to the end user and 5322.From is the only
> identifier that even comes close to being the right one.
And that comes from t
On Jun 8, 2014, at 5:31 PM, Terry Zink wrote:
>> Hector Santos wrote:
>>
>>> It is mentioned in Section 6, but the mention there doesn't even say
>>> that it's the DMARC result that's supposed to be recorded. That bit
>>> at least needs to be fixed.
>>>
>>> Anyone else have a comment?
>
>>
On 6/9/2014 10:38 PM, Barry Leiba wrote:
Putting as much value on RFC5322 From as DMARC does follows
conventional wisdom, but I believe that wisdom is flawed.
Of course, that speaks to the advice you want to give: tell UIs that
they should show the From addr-spec to users always. But be clear
a
On Monday, June 09, 2014 22:38:54 Barry Leiba wrote:
> >>Putting as much value on RFC5322 From as DMARC does follows
> >>conventional wisdom, but I believe that wisdom is flawed.
> >>
> >>Of course, that speaks to the advice you want to give: tell UIs that
> >>they should show the From addr-spec to
>>Putting as much value on RFC5322 From as DMARC does follows
>>conventional wisdom, but I believe that wisdom is flawed.
>>
>>Of course, that speaks to the advice you want to give: tell UIs that
>>they should show the From addr-spec to users always. But be clear
>>about what you're asking for: yo
On Monday, June 09, 2014 5:15 PM [GMT+1=CET], Barry Leiba wrote:
> > We based DMARC spec on the From header because it is visible to the
> > end user.
>
> Yes.
> Unfortunately, that's sort of a red herring. Most email clients show
> the "pretty text" of the From (the display-name ABNF construct)
On Monday, June 09, 2014 10:54 AM [GMT+1=CET], Stephen J. Turnbull wrote:
> John Levine writes:
>
> > Recording stuff in A-R is fine. Advice about how MUAs should
> display > them is not. Considering the dismal history of browser
> warnings about > bad SSL certs, I would expect any user inte
John Levine writes:
> People made this suggestion for l= DKIM signatures, too.
l= DKIM signatures are a bad idea, precisely because in existing MUAs
there will be no indication of what is covered by the signature, and
what not. "Nobody" does that.
But now mailing lists and other mediators are
On Mon, Jun 9, 2014 at 8:15 AM, Barry Leiba wrote:
> Unfortunately, that's sort of a red herring. Most email clients show
> the "pretty text" of the From (the display-name ABNF construct) if it
> exists, and actually *hide* the actual address (the addr-spec ABNF
> construct).
>
> Putting as much
On June 9, 2014 11:15:18 AM EDT, Barry Leiba wrote:
>> We based DMARC spec on the From header because it is visible to the
>end
>> user.
>
>Yes.
>Unfortunately, that's sort of a red herring. Most email clients show
>the "pretty text" of the From (the display-name ABNF construct) if it
>exists, an
> We based DMARC spec on the From header because it is visible to the end
> user.
Yes.
Unfortunately, that's sort of a red herring. Most email clients show
the "pretty text" of the From (the display-name ABNF construct) if it
exists, and actually *hide* the actual address (the addr-spec ABNF
cons
>Similarly in case of bypassing DMARC by wrapping the message, or a
>length limit on the DKIM signature, IWBNI the unauthenticated parts of
>the message were given a "nice UX" treatment semantically equivalent
>to displaying it in grey45 on grey50, adding a big warning in red
>explaining that From:
John Levine writes:
> Recording stuff in A-R is fine. Advice about how MUAs should display
> them is not. Considering the dismal history of browser warnings about
> bad SSL certs, I would expect any user interface advice we give to be
> counterproductive.
Agreed. However, in case of "p=qua
>It is mentioned in Section 6, but the mention there doesn't even say that
>it's the DMARC result that's supposed to be recorded. That bit at least
>needs to be fixed.
>
>Anyone else have a comment?
Recording stuff in A-R is fine. Advice about how MUAs should display
them is not. Considering th
> Hector Santos wrote:
>
>> It is mentioned in Section 6, but the mention there doesn't even say
>> that it's the DMARC result that's supposed to be recorded. That bit
>> at least needs to be fixed.
>>
>> Anyone else have a comment?
>
> Only that it goes back to the similar SPF thing regarding
On Sunday, June 8, 2014 5:30 PM, Murray S. Kucherawy
wrote:
> I'm not so sure about the SHOULD
i would stay with SHOULD/MUST combo. i would, actually, even
suggest it to be MUST/MUST combo, but i leave that to general
consensus, as there may be reasons not to go so strong, which
i'm not curren
On 6/8/2014 11:30 AM, Murray S. Kucherawy wrote:
On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj
Only that it goes back to the similar SPF thing regarding dynamic
rejections. So to be consistent for DMARC:
DMARC POLICY A-R Trace Guideline
REJECT --> N/A see 55x reply codes.
QUARANTI
On 6/8/2014 7:18 PM, Stephen J. Turnbull wrote:
> If we want to
> ask the MUA developers to do something to inform the end user about
> authentication results, we sure as shooting should put our protocol
> where our mouth is by putting in a requirement that MTAs give them
> that information.
Havi
Murray S. Kucherawy writes:
> I'm not so sure about the SHOULD because the only interoperability
> A-R enables is stuff between the verifiers and the MUAs and humans,
> really. It certainly wouldn't be a bad idea for us to highlight
> how useful it would be though.
I'm in strong agreement wi
Franck Martin writes:
> So I'm happy with advice to MTA, and I still think we should do an
> advice to the MUA, by telling what is important to us.
I think the BCP is the appropriate place for recommendations to the
MUA. SPF, DKIM, and DMARC are a couple of protocol layers lower than
what MUA d
- Original Message -
> From: "Murray S. Kucherawy"
> To: "Vlatko Salaj"
> Cc: dmarc@ietf.org
> Sent: Sunday, June 8, 2014 5:30:33 PM
> Subject: Re: [dmarc-ietf] advice to MTAs
> On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj < vlatko.sa...
On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj
wrote:
> imo, what all current DMARC deployments lack is notice to
> end receiver mailbox about any DMARC validation done on a
> particular message, and how it validated.
>
> thus, similarly to Franck's Advice to MUAs, i would propose
> adding this ki
imo, what all current DMARC deployments lack is notice to
end receiver mailbox about any DMARC validation done on a
particular message, and how it validated.
thus, similarly to Franck's Advice to MUAs, i would propose
adding this kind of txt to DMARC draft:
"DMARC participating MTAs SHOULD inclu
25 matches
Mail list logo
