On Tue 03/Dec/2019 21:22:28 +0100 Murray S. Kucherawy wrote:
> Assuming the ptype we're talking about is "dns" which is defined in the same
> document, the definition is terse and there's not much guidance for the
> designated expert about what things should be allowed with respect to future
>
On Wed 04/Dec/2019 08:13:48 +0100 Scott Kitterman wrote:
> I'd prefer to see the new dns ptype separated from the dnswl discussion. I
> can see broad utility in the dns ptype (for example, if you want to indicate
> that a domain is testing DKIM, I think we need dns because that's where you
>
On Tue 03/Dec/2019 21:22:28 +0100 Murray S. Kucherawy wrote:
> As far as I know we're talking about "dnswl" which is a method, not a ptype.
> There is one known implementation (CourierMTA, I believe) which is the impetus
> for the registration. I think the name is constrained to whitelists even
On Tuesday, December 3, 2019 4:21:47 PM EST John R Levine wrote:
> On Tue, 3 Dec 2019, Murray S. Kucherawy wrote:
> > On Mon, Nov 11, 2019 at 7:54 AM John Levine wrote:
> Nice to know I'm not the only one who lets my mail marinate for a while.
>
> > Assuming the ptype we're talking about is
On Mon, Nov 11, 2019 at 7:54 AM John Levine wrote:
> In article dx...@mail.gmail.com> you write:
> >Just to be clear: The policy for changes to that registry is "Expert
> >Review", but since the action that put it there was a document with IETF
> >consensus, I'm pretty hesitant about just
On November 11, 2019 3:54:09 PM UTC, John Levine wrote:
>In article
>
>you write:
>>Just to be clear: The policy for changes to that registry is "Expert
>>Review", but since the action that put it there was a document with
>IETF
>>consensus, I'm pretty hesitant about just approving this change
In article
you write:
>Just to be clear: The policy for changes to that registry is "Expert
>Review", but since the action that put it there was a document with IETF
>consensus, I'm pretty hesitant about just approving this change based on a
>formal request. I'd rather at least see some
On 11/11/2019 06:30, Murray S. Kucherawy wrote:
>> Authentication-Results: example.com;
>> dkim=pass dns.sec=yes header.i=@example.org header.b=j5aQ3SJv
>>
>
> Are there any MTAs that would take a different action based on this
> information?
For Exim it would be a fairly simple bit of
On Mon 11/Nov/2019 07:30:05 +0100 Murray S. Kucherawy wrote:
> On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote:
>
>> About the new ptype, a reviewer suggested to also use it to report
>> whether the query supported DNSSEC. No DNSWL that I know supports it.
>> However, I know some DKIM
On Sun, Nov 10, 2019 at 10:30 PM Murray S. Kucherawy
wrote:
> On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote:
>
>> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
>> >
>> >> If the definition of ptype smtp were "a parameter of the SMTP session
>> used
>> >> to relay the
On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote:
> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
> >
> >> If the definition of ptype smtp were "a parameter of the SMTP session
> used
> >> to relay the message" it would be perfect. I'd propose that
> policy.iprev
> >> be
Hi Tim,
The I-D linked below provides for yes, no (not signed), or na (for not
applicable). The expired case should perhaps map to "no"? The lookup only
sets an AD bit...
Best
Ale
On Mon 21/Oct/2019 19:49:03 +0200 Tim Wicinski wrote:
>
> Alessandro
>
> There are a couple of different
Alessamdro
There are a couple of different combinations of dnssec
valid/invalid/expired you would want to account for.
Tim
On Mon, Oct 21, 2019 at 10:54 AM Alessandro Vesely wrote:
> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
> >
> >> If the definition of ptype smtp were "a
On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
>
>> If the definition of ptype smtp were "a parameter of the SMTP session used
>> to relay the message" it would be perfect. I'd propose that policy.iprev
>> be deprecated and smtp.remote-ip used instead>>
>
> Given that RFC8601 was
On Fri, 9 Aug 2019, at 12:04 PM, Stan Kalisch wrote:
> On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy wrote:
>> On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote:
>>> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/,
>>> does not contain the term "policy".
>>
On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy wrote:
> On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote:
>> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/,
>> does not contain the term "policy".
>
> Wow. I'm amazed I got away with that.
>
> But it is
On Wed 07/Aug/2019 17:14:22 +0200 Murray S. Kucherawy wrote:
> On Sat, Aug 3, 2019 at 8:28 AM Alessandro Vesely wrote:
>>
>> IOW, dnswl=pass means the sender was whitelisted.
>
>
> If that's the case, why do downstream agents need "policy.ip" at all?
To be whitelisted just means that the
On Sat, Aug 3, 2019 at 8:40 AM Alessandro Vesely wrote:
> That's much better. If the definition of ptype smtp were "a parameter of
> the
> SMTP session used to relay the message" it would be perfect. I'd propose
> that
> policy.iprev be deprecated and smtp.remote-ip used instead.
>
Given that
On Sat, Aug 3, 2019 at 8:28 AM Alessandro Vesely wrote:
> IOW, dnswl=pass means the sender was whitelisted.
>
If that's the case, why do downstream agents need "policy.ip" at all?
-MSK
___
dmarc mailing list
dmarc@ietf.org
On August 2, 2019 7:58:30 PM UTC, "Murray S. Kucherawy"
wrote:
>For guidance here, I would rely on anecdotes of implementation. Has
>anyone
>implemented something that attaches "iprev" results?
The authres Python module that I maintain has implemented the structure and has
On 02/08/2019 20:58, Murray S. Kucherawy wrote:
> For guidance here, I would rely on anecdotes of implementation. Has anyone
> implemented something that attaches "iprev" results?
Exim does.
--
Cheers,
Jeremy
___
dmarc mailing list
dmarc@ietf.org
On Fri 02/Aug/2019 19:22:50 +0200 Kurt Andersen (b) wrote:
> On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote:
>
>> To stick with A-R semantics, it should have been named tcp.ip, remote.ip
>> or some such.>>
>
> Note that RFC8617 section 10.2 (
>
On Fri 02/Aug/2019 21:58:30 +0200 Murray S. Kucherawy wrote:
>
> Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"?
> I would expect it to have that knowledge, not downstream things. Again, I
> don't know what the value of "dnswl=pass" is if the thing attaching it
>
On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote:
> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/,
> does not contain the term "policy".
>
Wow. I'm amazed I got away with that.
But it is clear from the things in the registry that that's how you do it.
My
On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote:
> To stick with A-R semantics, it should have been named
> tcp.ip, remote.ip or some such.
>
Note that RFC8617 section 10.2 (
https://tools.ietf.org/html/rfc8617#section-10.2) does add in an
smtp.remote-ip method item.
--Kurt
On Fri 02/Aug/2019 00:15:30 +0200 Scott Kitterman wrote:
> Taking a step back, iprev uses the policy ptype. It's also based on local
> interpretation of DNS data. Why doesn't policy work for dnswl just like for
> iprev?
Let me note that Section 3 of rfc8601, /The "iprev" Authentication
Taking a step back, iprev uses the policy ptype. It's also based on local
interpretation of DNS data. Why doesn't policy work for dnswl just like for
iprev?
Scott K
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
27 matches
Mail list logo
