Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

On 2022-02-06 21:44, [e-mail] wrote:
>
>
> These are closer to implementation, yes. But how SIEVE is used is that 
> a mail server operator can be on one network and they have users on 
> other networks that use this protocol to tell the operator what their 
> mail filtering preferences are. So mail server operator (if they were 
> behind NAT64) would have to do this re-writing or re-interpretation of 
> SIEVE rules. This may require knowledge of how IPv4 is mapped to IPv6 
> for them. And it is not much different than trying to re-interpret SPF 
> records when on IPv6 only network.
>
 From my perspective SPF should be covered as it's also DNS and when 
doing DNS64 it's reasonable for the admin to assume that it's consistent 
and complete. Therefore translating the SPF would be something that 
anyone using DNS64 would take as given.

SIEVE on the other hand isn't part of DNS. I'd consider it more like a 
firewall. Another system that does filtering utilizing DNS but not being 
part of DNS. And for those systems there is RFC7050 
https://datatracker.ietf.org/doc/html/rfc7050#section-3.4 or the admin 
manually updating the IPs in the configuration.

But for SPF on the other hand we're basically serving incorrect 
information from an admins perspective. As DNS64+NAT64 should make the 
IPv4 internet a part of the ipv6 only internet, but then it doesn't 
serve ipv6 IPs within the SPF...

> One of the ways of solving issues like this is special IPv4 in-addr 
> like dns map and lookup which would allow hosts behind NAT64 to find 
> what IPv4->IPv6 translation for their site is when they have an IPv4 
> address from some filtering system or protocol and they need to 
> locally re-interpret it. This is not as elegant as DNS64 rewriting but 
> I think its going to be needed in the end anyway for various cases 
> (maybe as interim solution).
>
> On 2022-02-06 12:21, Klaus Frank wrote:
>
>> 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
>>
>> _______________________________________________
>> spfbis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spfbis