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 <[email protected]> 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 recollection is that reporting the
>>> client IP is immaterial, as for SPF. The term policy.iprev is certainly
>>> misleading, since the value is not related to a locally-defined policy, and 
>>> is
>>> not a reversed ip. To stick with A-R semantics, it should have been named
>>> tcp.ip, remote.ip or some such. If a property warrants deprecation, it's
>>> policy.iprev.
>> 
>> The choice of "policy" for "iprev" is rooted in history, because the earlier 
>> versions of the document (as you well know) demanded that the things being 
>> reported had something to do with the message itself. "iprev" was an 
>> exception the community chose to allow. It pre-dated RFC5782 which 
>> introduced DNSxLs formally.
>> 
>> For guidance here, I would rely on anecdotes of implementation. Has anyone 
>> implemented something that attaches "iprev" results?
> 
> IIRC, Fastmail's Authentication Milter does. But I also have some vague 
> recollection that they stopped using policy.iprev, specifically.
> 
> Now looking at headers from my Fastmail customer account, it appears to me 
> that this is indeed what they did, although I would have to recheck the 
> actual distribution they share with everyone else to be sure. I'm sure 
> someone at Fastmail can comment on what actually precipitated the move.

We (Fastmail) do attach IPRev results. We used policy.iprev for the remote IP 
up until October 2018, although it may have been slightly later when the change 
made it through to production. I recall the change being made as part of a 
larger set of changes which came out of an ARC interop working session.
Current code uses smtp.remote-ip for a few reasons, mostly as it is more 
correct to attach this to the IP to the smtp type, it is also more in line with 
what some other providers are doing. For context, we are using this when 
processing messages with a trusted ARC set.

--

 Marc Bradshaw
marcbradshaw.net | @marcbradshaw <https://twitter.com/marcbradshaw>

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to