Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

But if I see that correctly that's a list that the admin of the 
recipient side has under his control and could update, right? Therefore 
the same entity that deploys DNS64 would just have to make sure to also 
update the list of IPs within their SIEVE configuration, right?

If so a possible migration would be to duplicate these sections with the 
corresponding NAT64 addresses and after NAT64+DNS64 is deployed for the 
mail infrastructure to decommission the ipv4 only ones.

This doesn't look like a hard/RFC limitation (like the SPF record thing) 
to me. Or am I missing something?

On 2022-02-06 21:10, [e-mail] wrote:
>
>
> In regards to SIEVE take a look at examples in 
> http://www.delegate.org/ietf/rfc-html/rfc6134.shtml
>
> There are a lot of various types of ip address validation going on 
> that is not documented by IETF or any other authority but is in 
> practice done using various unix utilities. Most of these is just to 
> separate local and external networks but there are real ip address 
> blocks of large sties - both at the router/network and at the local 
> host level. Some companies limit what sites their employees can visit 
> and there are many ways it is done.
>
> And of course for email ip address block lists still exists and in use 
> as well. In some cases DNS is used, in others ip lists are received as 
> files and synced.
>
> NAT64 is bound to run into all sorts of issues like this when it 
> begins to be more widely used. And I do think this is positive step 
> towards IPv6 world. Its just going to take quite some time to work all 
> these issues out.
>
> On 2022-02-06 11:13, Klaus Frank wrote:
>
>> I'm not aware that SIEVE would use the source ip address. Also when 
>> looking over the main RFCs for it I couldn't find anything that 
>> specifies ip validation. ATM only the EHLO (which uses the PTR-RR) 
>> and the SPF validation rely on IP to DNS mapping.
>>
>> On 2022-02-06 19:55, [e-mail] wrote:
>>>
>>>
>>> This is like NAT where entirety of DNS is re-written to make 
>>> internet appear to be IPV6 only. So yes, SPF records would be an 
>>> issue then.
>>>
>>> There is more than one way to solve it. The proposal to re-write SPF 
>>> is probably the most correct way within context of NAT64-DNS64. The 
>>> other option would be to update SPF specifying that validating 
>>> servers on IPv6 only network can use IPv4 spf records for validation 
>>> if the ip address of connecting mail server is a mapped IPv4->IPv6. 
>>> That is far less elegant though.
>>>
>>> BTW, I bet SPF is not going to be the only protocol with these types 
>>> of issues. How about SIEVE? Have you checked how well NAT64 
>>> inter-operates with that?
>>>
>>> On 2022-02-06 10:25, Scott Kitterman wrote:
>>>
>>>> On Sunday, February 6, 2022 1:09:13 PM EST Klaus Frank wrote:
>>>>> Hi,
>>>>>
>>>>> we had some issues with SPF and a mail server that was behind
>>>>> NAT64+DNS64. I at first thought that it was just a misconfiguration. But
>>>>> after the DNS64 server seamed to work as intended I went to the
>>>>> implementation and the RFC. Thereby while reading RFC6147 I stumbled
>>>>> across section 5.3.3 which says "All other RRs MUST be returned
>>>>> unchanged." which is the cause of my issues. This section is basically
>>>>> ignoring SPF records (RFC7208 section 5.6) and also preventing DNS64
>>>>> implementations from addressing this limitation.
>>>>>
>>>>> Would it be possible to create an extension to RFC6147 that mandates SPF
>>>>> record rewrites as well? Otherwise Mail servers behind NAT64+DNS64 in
>>>>> IPv6 only environments won't be able to work as expected.
>>>>>
>>>>> Like:
>>>>> If the DNS64 server receives a SPF-record (within either the TXT-RR or
>>>>> the SPF-RR [RFC4408]) containing the "ip4" mechanism it MUST rewrites
>>>>> the ipv4 address according to the same rules as A-records are and
>>>>> synthesizes a new SPF record within the response that contains
>>>>> additional "ip6" entries. The original "ip4" should not be removed from
>>>>> the response.
>>>>
>>>> What's preventing the SPF record publisher from solving this 
>>>> problem by adding
>>>> the ip6: mechanisms themselves?  Perhaps I don't understand the 
>>>> issue you are
>>>> raising.  Would you please clarify what it is you're asking be done 
>>>> that an
>>>> administrator can't do on their own?
>>>>
>>>> Scott K
>>>>
>>>>
>>>> _______________________________________________
>>>> spfbis mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spfbis
>>>
>>> _______________________________________________
>>> spfbis mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spfbis
>>
>> _______________________________________________
>> spfbis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spfbis