On 5/19/15 8:25 PM, John Levine wrote:
>> The challenge here is that the second signer may not have anything to do
>> with
>> the message. Since, except for From, only invisible parts of the message
>> are
>> signed, the signature could be applied to almost any email. Using the
>> reputati
On Wednesday, May 20, 2015 03:25:28 AM John Levine wrote:
> >The challenge here is that the second signer may not have anything to do
> >with the message. Since, except for From, only invisible parts of the
> >message are signed, the signature could be applied to almost any email.
> >Using the re
>The challenge here is that the second signer may not have anything to do with
>the message. Since, except for From, only invisible parts of the message are
>signed, the signature could be applied to almost any email. Using the
>reputation of the second signer's domain is not substantially dif
On Tuesday, May 19, 2015 11:40:21 PM John Levine wrote:
> >I would think you'd have to. There's a replay risk that's unique to this
> >type of signature, so I think treating them the same would be a naive
> >approach.
> Remember that DMARC doesn't tell you that a message is good. The most
> it can
On 5/19/15 3:56 PM, Murray S. Kucherawy wrote:
> On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy
> wrote:
>> On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld <
>> r.e.sonnev...@sonnection.nl> wrote:
>>
>>> But when somebody gets around to trying to exploit this
window,
>>> sites with quick
>I would think you'd have to. There's a replay risk that's unique to this type
>of
>signature, so I think treating them the same would be a naive approach.
Remember that DMARC doesn't tell you that a message is good. The most
it can say is "not so awful that you should automatically reject it."
On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy
wrote:
> On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld <
> r.e.sonnev...@sonnection.nl> wrote:
>
>
>> But when somebody gets around to trying to exploit this window, sites
>> with quick (re-)delivery to most of their recipients will probab
On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld <
r.e.sonnev...@sonnection.nl> wrote:
>
> But when somebody gets around to trying to exploit this window, sites with
> quick (re-)delivery to most of their recipients will probably want to cut
> the length of that exposure down...
>
>
> which effe
On Tue, May 19, 2015 at 1:58 PM, Steven M Jones wrote:
> 6. What is the proposed t= time limit? Is 30 seconds enough? Too
> long? Too little?
>
> I would guess too little, but at this point that's strictly a guess.
> You need to leave enough time for possible network or other transmission
>> What would the Authentication-Results header look like? Presumably 3
>> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC?
>> Show one result or two? Or maybe something like dmarc=conditionalpass? ...
>Is there any use in making a distinction to your acceptance/routing of
On 05/19/2015 10:58 PM, Steven M Jones wrote:
On 05/19/2015 13:01, Murray S. Kucherawy wrote:
On Tue, May 19, 2015 at 12:00 PM, Terry Zink
mailto:tz...@exchange.microsoft.com>>
wrote:
6.What is the proposed t= time limit? Is 30 seconds enough? Too
long? Too little?
I would guess too
On 05/19/2015 13:01, Murray S. Kucherawy wrote:
On Tue, May 19, 2015 at 12:00 PM, Terry Zink
mailto:tz...@exchange.microsoft.com>>
wrote:
6.What is the proposed t= time limit? Is 30 seconds enough? Too
long? Too little?
I would guess too little, but at this point that's strictly a gue
On 05/19/2015 10:01 PM, Murray S. Kucherawy wrote:
On Tue, May 19, 2015 at 12:00 PM, Terry Zink
mailto:tz...@exchange.microsoft.com>>
wrote:
I think we’re making progress here. So, a message would look like
this:
From: joe@authordomain.example
Authentication-Results: spf=pass
Yeah, sorry, I confused the t= with x= in the DKIM signature.
-- Terry
From: Murray S. Kucherawy [mailto:superu...@gmail.com]
Sent: Tuesday, May 19, 2015 1:02 PM
To: Terry Zink
Cc: Scott Kitterman; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries -
Effo
On Tue, May 19, 2015 at 12:00 PM, Terry Zink
wrote:
> I think we’re making progress here. So, a message would look like this:
>
>
> From: joe@authordomain.example
> Authentication-Results: spf=pass (sender IP is xx.xx.xx.xx)
> smtp.mailfrom=mlm.example;
> dkim=fail (invalid body hash) header
On 5/19/2015 2:39 PM, Murray S. Kucherawy wrote:>
Terry Zink
Putting it into a comment is fine, maybe something like
additional fields like that into A-R, isn’t it?
More like:
dmarc=pass header.from= (action=, cd=)
IMO, this makes it a DMARC extension.
Is draft-levine-dkim-condition
On 5/19/15 4:47 AM, Scott Kitterman wrote:
> On May 19, 2015 2:05:18 AM EDT, "Murray S. Kucherawy"
> wrote:
>> On Mon, May 18, 2015 at 10:56 PM, Terry Zink
>>
>> wrote:
>>
>>> Thanks, this is useful.
>>>
>>> What would the Authentication-Results header look like? Presumably 3
>>> results for
I think we’re making progress here. So, a message would look like this:
From: joe@authordomain.example
Authentication-Results: spf=pass (sender IP is xx.xx.xx.xx)
smtp.mailfrom=mlm.example;
dkim=fail (invalid body hash) header.d=authordomain.example
dkim=pass (signature was verified) head
On Tue, May 19, 2015 at 11:24 AM, Terry Zink
wrote:
> > Sure, but can it just be in a comment if you find that useful, or is
> it necessary to
> > make that fact something a consumer of the field can parse out?
>
> Putting it into a comment is fine, maybe something like “dmarc=pass
> action=none
> Sure, but can it just be in a comment if you find that useful, or is it
> necessary to
> make that fact something a consumer of the field can parse out?
Putting it into a comment is fine, maybe something like “dmarc=pass action=none
header.from= conditional.to=”. I think it’s
permissible to ad
On Tue, May 19, 2015 at 9:19 AM, Terry Zink
wrote:
> >> I would think you'd have to. There's a replay risk that's unique to
> this type of
>
> >> signature, so I think treating them the same would be a naive approach.
>
>
>
> > But is that something that an agent downstream of a verifier needs t
>> I would think you'd have to. There's a replay risk that's unique to this
>> type of
>> signature, so I think treating them the same would be a naive approach.
> But is that something that an agent downstream of a verifier needs to know?
> A-R for SPF doesn't differentiate between "-all" and "~
On Tue, May 19, 2015 at 4:47 AM, Scott Kitterman
wrote:
> >Is there any use in making a distinction to your acceptance/routing of
> >messages to know it was based on a conditional signature versus an
> >original
> >author signature?
>
> I would think you'd have to. There's a replay risk that's un
On May 19, 2015 2:05:18 AM EDT, "Murray S. Kucherawy"
wrote:
>On Mon, May 18, 2015 at 10:56 PM, Terry Zink
>
>wrote:
>
>> Thanks, this is useful.
>>
>> What would the Authentication-Results header look like? Presumably 3
>> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about
>DMAR
24 matches
Mail list logo