Deconstructing SPF with Rust using Generics

basman

Adam.S

Posted on April 10, 2021

Deconstructing SPF with Rust using Generics

As I mentioned in my previous article Deconstructing SPF Records with Rust. There is a case for using generics given the amount of overlap between the different mechanisms.

So in this article I will document how I transitioned from using unique structs for each mechanism, leading to less overall code and other benefits.

While I was considering how best to go about doing generics, I came across this very nice write up on dev.to entitled Rust Generic Types in Method Definitions. It's certainly worth a read.

A Refresher on the issue

Let's revisit some of the code from the previous article. Specifically we will just look at the struct for Include and Ip4:

Include

#[derive(Default, Debug, Clone)]
struct Include {
    qualifier: char,
    txt: String,
}
Enter fullscreen mode Exit fullscreen mode

This is pretty straight forward. It holds a qualifier of char, and a txt of String. Other mechanisms in SPF use the exact same basic components. Specifically, A and MX. Redirect also uses the same components, with the qualifier always being + or simply blank. But I need to duplicate this struct definition for each mechanim.

Not only do I need to create the same structs, I also need to then impl the same functions on each struct.

impl Include {
    fn new(qualifier: char, txt: String) -> Self {
        Self { qualifier, txt }
    }
    fn as_mechanism(&self) -> String {
        // rebuild and return the string represensation of a include mechanism
        let mut txt = String::new();
        if self.qualifier != '+' {
            txt.push(self.qualifier);
        }
        txt.push_str("include:");
        txt.push_str(self.txt.as_str());
        txt
    }
    fn is_pass(&self) -> bool {
        if self.qualifier == '+' {
            true
        } else {
            false
        }
    }
    fn is_fail(&self) -> bool {
        if self.qualifier == '-' {
            true
        } else {
            false
        }
    }
    fn is_softfail(&self) -> bool {
        if self.qualifier == '~' {
            true
        } else {
            false
        }
    }
    fn is_neutral(&self) -> bool {
        if self.qualifier == '?' {
            true
        } else {
            false
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

This also applies to ip4 and ip6

Ip4

#[derive(Debug, Clone)]
struct Ip4 {
    qualifier: char,
    ip: IpNetwork,
}

impl Ip4 {
    fn new(qualifier: char, ip: IpNetwork) -> Self {
        Self { qualifier, ip }
    }
    fn as_string(&self) -> String {
        self.ip.to_string()
    }
    fn as_mechanism(&self) -> String {
        let mut ip4_string = String::new();
        if self.qualifier != '+' {
            ip4_string.push(self.qualifier);
        }
        ip4_string.push_str("ip4:");
        ip4_string.push_str(self.ip.to_string().as_str());
        ip4_string
    }
    fn as_ip(&self) -> IpNetwork {
        self.ip
    }
    fn is_pass(&self) -> bool {
        if self.qualifier == '+' {
            true
        } else {
            false
        }
    }
    fn is_fail(&self) -> bool {
        if self.qualifier == '-' {
            true
        } else {
            false
        }
    }
    fn is_softfail(&self) -> bool {
        if self.qualifier == '~' {
            true
        } else {
            false
        }
    }
    fn is_neutral(&self) -> bool {
        if self.qualifier == '?' {
            true
        } else {
            false
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

Doing things with Generics

My initial idea was to simply make a generic struct as follows.

#[derive(Debug, Clone)]
struct SpfMechanism<T> {
    qualifier: char,
    mechanism: T,
}
Enter fullscreen mode Exit fullscreen mode

And then impliment the functions that would apply to all instance types of SpfMechanism. But as I sat thinking about it. I realised it wouldn't work. Because the as_mechanism() function would need to be able to differentiate between a redirect, include, and so on. I needed to be able to use as_mechanism and create records similar to include:_spf.example.com, ip4:X.X.X.X, a, mx:mx-host.example.com and so on.

I realised I would need to actually have a unique type/kind for each mechanism, and so I added an enum; listing the kinds of mechanisms

#[derive(Debug, Clone)]
enum MechanismKind {
    Include,
    Redirect,
    A,
    MX,
    IpV4,
    IpV6,
    All,
}
Enter fullscreen mode Exit fullscreen mode

And I updated the SpfMechanism to be

#[derive(Debug, Clone)]
struct SpfMechanism<T> {
    kind: MechanismKind,
    qualifier: char,
    mechanism: T,
}

Enter fullscreen mode Exit fullscreen mode

Throw in a little magic so I can test the what Kind the SpfMechanism is:

Note: This was generated by my editor with a click of a button.

impl MechanismKind {
    /// Returns `true` if the mechanism_kind is [`Include`].
    fn is_include(&self) -> bool {
        matches!(self, Self::Include)
    }
    /// Returns `true` if the mechanism_kind is [`A`].
    fn is_a(&self) -> bool {
        matches!(self, Self::A)
    }

    /// Returns `true` if the mechanism_kind is [`MX`].
    fn is_mx(&self) -> bool {
        matches!(self, Self::MX)
    }

    /// Returns `true` if the mechanism_kind is [`IpV4`].
    fn is_ip_v4(&self) -> bool {
        matches!(self, Self::IpV4)
    }

    /// Returns `true` if the mechanism_kind is [`IpV6`].
    fn is_ip_v6(&self) -> bool {
        matches!(self, Self::IpV6)
    }

    /// Returns `true` if the mechanism_kind is [`All`].
    fn is_all(&self) -> bool {
        matches!(self, Self::All)
    }

    /// Returns `true` if the mechanism_kind is [`Redirect`].
    fn is_redirect(&self) -> bool {
        matches!(self, Self::Redirect)
    }
}
Enter fullscreen mode Exit fullscreen mode

Next I wanted to implement the functions that would be applied to all SpfMechanism irrespective of the mechanism type, be it String or IpNetwork

All mechanism types support these functions.

impl<T> SpfMechanism<T> {
    fn new(kind: MechanismKind, qualifier: char, mechanism: T) -> Self {
        Self {
            kind,
            qualifier,
            mechanism,
        }
    }
    fn is_pass(&self) -> bool {
        self.qualifier == '+'
    }
    fn is_fail(&self) -> bool {
        self.qualifier == '-'
    }
    fn is_softfail(&self) -> bool {
        self.qualifier == '~'
    }
    fn is_neutral(&self) -> bool {
        self.qualifier == '?'
    }
    fn mechanism_prefix_from_kind(&self) -> String {
        let push_str = match self.kind {
            MechanismKind::Redirect => "redirect=",
            MechanismKind::Include => "include:",
            MechanismKind::A => "a:",   // requires modification
            MechanismKind::MX => "mx:", // requires modication
            MechanismKind::IpV4 => "ip4:",
            MechanismKind::IpV6 => "ip6:",
            MechanismKind::All => "",
        };
        push_str.to_string()
    }
}
Enter fullscreen mode Exit fullscreen mode

The important thing to note here is that impl<T> is what makes these functions able to work no matter what <T> ultimately turns out to be.

Implementing SpfMechanism for redirect, include, a, and mx

These mechanism all share a common type of String for T but we do not need to recode the is_* functions. So we need to implement as_string() and as_mechanism() only at this time. You might noticed as you read through that as_mechanism() makes use of the mechanism_prefix_from_kind() function which is defined for the generic SpfMechanism

I also decided to implement new_* for each mechanism type. These are essentially aliases to SpfMechanism::new()

impl SpfMechanism<String> {
    fn new_include(qualifier: char, mechanism: String) -> Self {
        SpfMechanism::new(MechanismKind::Include, qualifier, mechanism)
    }
    fn new_redirect(qualifier: char, mechanism: String) -> Self {
        SpfMechanism::new(MechanismKind::Redirect, qualifier, mechanism)
    }
    fn new_all(qualifier: char, mechanism: String) -> Self {
        SpfMechanism::new(MechanismKind::All, qualifier, mechanism)
    }
    fn as_mechanism(&self) -> String {
        // rebuild and return the string representation of a include, redirect, a or mx mechanism
        let mut txt = String::new();
        if self.qualifier != '+' {
            txt.push(self.qualifier);
        } else {
            // Do nothing omitting '+'
        }
        if self.kind.is_all() {
            txt.push_str("all")
        } else {
            txt.push_str(self.mechanism_prefix_from_kind().as_str());
            txt.push_str(self.mechanism.as_str());
        }
        txt
    }
    fn as_string(&self) -> &String {
        &self.mechanism
    }
}
Enter fullscreen mode Exit fullscreen mode

The real payoff here is that we have a single as_mechanism() and as_string() which works for all SpfMechanism where <T> is of type String. Those being redirect, include a, mx and all. Within as_mechanism(), I call mechanism_prefix_from_kind() to get the correct prefix string, be it include:, redirect= and so on.

Implementing SpfMechanism for Ip4 and Ip6

Ip4 and Ip6 are both of type IpNetwork the only difference being they are written as ip4:X.X.X.X and ip6:xxxx:xxxx:...

impl SpfMechanism<IpNetwork> {
    fn new_ip4(qualifier: char, mechanism: IpNetwork) -> Self {
        SpfMechanism::new(MechanismKind::IpV4, qualifier, mechanism)
    }
    fn new_ip6(qualifier: char, mechanism: IpNetwork) -> Self {
        SpfMechanism::new(MechanismKind::IpV6, qualifier, mechanism)
    }
    fn as_mechanism(&self) -> String {
        // rebuild and return the string represensation of a include, redirect mechanism
        let mut txt = String::new();
        if self.qualifier != '+' {
            txt.push(self.qualifier);
        } else {
            // Do nothing omitting '+'
        }
        txt.push_str(self.mechanism_prefix_from_kind().as_str());
        txt.push_str(self.mechanism.to_string().as_str());
        txt
    }
    fn as_string(&self) -> String {
        self.mechanism.to_string()
    }
}
Enter fullscreen mode Exit fullscreen mode

In my previous article I didn't actually implement the ip6: records.
Now, using this more generic approach, by adding merely a few lines of code. I have been able to implement ip6

Test Output for _netblocks2.google.com

List of TXT records found for _netblocks2.google.com.
TXT Record 1:
v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all

Decontructing SPF Record
Spf1 { source: "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all", include: None, redirect: None, is_redirected: false, a: None, mx: None, ip4: None, ip6: Some([SpfMechanism { kind: IpV6, qualifier: '+', mechanism: V6(Ipv6Network { addr: 2001:4860:4000::, prefix: 36 }) }, SpfMechanism { kind: IpV6, qualifier: '+', mechanism: V6(Ipv6Network { addr: 2404:6800:4000::, prefix: 36 }) }, SpfMechanism { kind: IpV6, qualifier: '+', mechanism: V6(Ipv6Network { addr: 2607:f8b0:4000::, prefix: 36 }) }, SpfMechanism { kind: IpV6, qualifier: '+', mechanism: V6(Ipv6Network { addr: 2800:3f0:4000::, prefix: 36 }) }, SpfMechanism { kind: IpV6, qualifier: '+', mechanism: V6(Ipv6Network { addr: 2a00:1450:4000::, prefix: 36 }) }, SpfMechanism { kind: IpV6, qualifier: '+', mechanism: V6(Ipv6Network { addr: 2c0f:fb50:4000::, prefix: 36 }) }]), all_qualifier: '~' }
SPF1: v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all

There are no include elements
There are no ip4 networks
There are no ip4 spf records.
List of ip6 networks/hosts:
2001:4860:4000::/36
2404:6800:4000::/36
2607:f8b0:4000::/36
2800:3f0:4000::/36
2a00:1450:4000::/36
2c0f:fb50:4000::/36

List of ip6 mechanisms:
ip6:2001:4860:4000::/36
ip6:2404:6800:4000::/36
ip6:2607:f8b0:4000::/36
ip6:2800:3f0:4000::/36
ip6:2a00:1450:4000::/36
ip6:2c0f:fb50:4000::/36

Is a redirect: false
Enter fullscreen mode Exit fullscreen mode

Code

The code for this aritcle can be found here

Final thoughts and thanks.

First, I would like to thank the people in the rust discord for answering my questions and making suggestions.

Also, this might not be the best solution. Exploring traits might be another way to go about getting things done.

Next steps?

I will consider breaking this single file up into seperate files to make the management easier. And learning to write actual tests. Always better to catch issues early.

💖 💪 🙅 🚩
basman
Adam.S

Posted on April 10, 2021

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related