Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[[e-mail]]

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.

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