Cannot add multiple ip4 mechanisms to an SPF record and some other SPF-related things

Bastille

Verified User
Joined
Mar 25, 2013
Messages
97
1) Given the wording and pop-up both say "addresses" (well, kind of... See below), it seems like the field should accept multiple IP addresses. It does not allow you to do so though nor does it recognize multiple ones already in place.

2) The label for that field is "IP Adresses", instead of "IP Addresses"

3) "Redirect domain" should be "Redirect Domain" to match the style used for the other labels

4) How will ip6 mechanisms be handled? Will they be in the same field as ip4 or will there be two rows, one for each?

5) What is the intended wording for the ptr mechanism's check box? "Allow any hostname ending in to send email for this domain" seems to be missing something

6) Should the redirect modifier be included at the top, rather than at the bottom above the all mechanism? It's not commonly used, to my knowledge at least, so it being featured at the top feels odd.
 
Thank you for the review and suggestions! May you check the latest version of the skin for the improvements? :)
 
It is an improvement, though there are still some quirks it seems.

Adding additional ip4 records is now possible but now you have to also include ip4: as a prefix when doing so. Also, the ip4 field seems to no longer take input in the manner it did previously though. It is just a standard text box, rather than displaying an empty "___.___.___.___/__".

If you submit multiple ip4 addresses, it will initially add them correctly. When you select to edit the SPF record again however, it will strip everything out but the ip address of the final one.


Two more as well:

1) The tooltip for the Redirect modifier is "The SPF record for domain replace the current record". That should read "for this domain replaces" or something to that effect, right?

2) There doesn't seem to be any error checking done against the 10 mechanism max limit that SPF has. When I included 15 different ip4 addresses as a test, it gladly accepted that and showed me a successful update.
 
Last edited:
Latest version of the skin allows you to add multiple IP addresses. May you check it now?
 
Thank you, that is certainly much cleaner than the previous method. Not sure how the previous method would have handled a default IPv6 instead of a IPv4 but this seems like it'd protect against that causing any problems. I don't have much experience working with IPv6 addresses to do any testing on that side of things unfortunately.

There are still a few lingering issues however:

1) It still lets me add more than 10 mechanisms and then returns a success upon doing so. Once 10 mechanisms are present,

2) When deleting ip mechanisms, it will always delete the top-most entry instead of the one you clicked on.

3) If you include a CIDR notation, it will save correctly the first time. Subsequent edits however will wind up reading the CIDR notation as part of the IP address, causing the CIDR notation to get doubled up. (EG 10.10.10.10/32 -> 10.10.10.10/32/32)

3a) If you delete a record, the CIDR notation is retained when pasting . This may be intended, rather than an actual bug, but feels weird due to issue 2 and then gets made a bit worse by issue 3.
EG ip4:10.10.10.10 ip4:192.168.1.1/24 -> Copy the 10.10.10.10 for the sake of easier re-entry due to the deletion bug -> Delete the second record -> Highlight the 192.168.1.1/24 that remains -> Paste the 10.10.10.10 -> You now have 10.10.10.10/24 showing

Minor quibbles that might trip up people who are less familiar with computers:

4) It forces you to click at the very start of the field to enter an IP address (or double click the field to highlight it, accomplishing the same effect). If you click anywhere else, it won't let you enter anything.

5) In order to enter CIDR notation, you need to enter a / to force it over there. You cannot just click past the / itself to enter it. This may also play a factor in 3a above.

6) Would it be possible to do similar labelling for the a and include fields (having the mechanism name on the left and then a + for the first entry, followed by delete symbols for subsequent ones)? They also suffer from the same issue that ip4 did, where multiple entries aren't parsed properly and only the last one survives if you re-open it. This would make it more obvious what you're adding when setting up the SPF record.

7) I messed up earlier with my testing as ip4, ip6, and all aren't counted towards the limit but it still let me do "a mx ptr include:_spf.google.com" and then 7 other a mechanisms without giving an error. That would be 11 mechanisms without factoring in that the Google include would be an extra 3 more. Include does make things messier for counting the number of mechanisms that perform DNS lookups but, at the very least, it should prevent users from going beyond 10.

8) If multiple include mechanisms are attempted, the new include mechanisms should come up with a warning about the hard limit of 10 mechanisms. There shouldn't really be a reason to use two (or, even worse, more) include mechanisms but it is still allowed, even if it it's highly frowned upon. It's an edge case that could spare some potential tickets/calls when a user insists on needing to use multiple include mechanisms.
 
May you check it one more time? Thank you for the suggestions.
 
The IP addresses do properly delete now, yes. That resolves point 2.
CIDR notation is properly saved, resolving point 3.
3a seems to be resolved as well.

4 is partially resolved, though in some ways it is now worse due to new issues. It will now always drag focus to the start of the field, regardless of whether the field is empty or filled out. This means when adjusting an existing record, you need to click twice. Once to select the field and then once more to actually select where you wanted to edit.

This wouldn't be so bad if not for the bug that happens when you do this for an entry that uses CIDR notation.
EG 10.10.10.0/24 -> Select Edit to Save -> Reopen the SPF editing page -> Click just once on the IP address and get taken to the start -> Start typing in the number 1 -> 10.10.10.0/24 turns into 111.111.010.100/24

Additionally, it doesn't seem to like short octets sometimes.
EG 192.168.1.1 -> Select Edit to Save -> Reopen the SPF editing page -> Click twice to edit the third octet -> Change the 1 into a 2 -> Suddenly 192.168.1.1__/__ becomes 192.168.21_.___/__

It also will not trim _ and will accept invalid records
EG 192.168.21_.___/__ will let itself be saved as well as 192.1_.1.1__/__ (which turns into 192.111.1__.___/__ if you type in a 1 at the start of the second octet)

End result was it reporting success to me for an SPF record of:
v=spf1 a mx ip4:(Our IP) ip4:111.111.010.100/24 ip4:192.168.0.1 ip4:192.168.21_._ ip4:192.111.1__._ ~all

As for the rest...
I cannot test 1/7 (duplicates because I forgot to finish off 1 initially and then wound up rewriting it for 7) because the main way to reach 10+ mechanisms is through the a mechanism. The SPF page currently requires you to enter a valid domain name and, as a result, will only let you include one entry into the server hostname area. The same applies for the include mechanism, though that's less important because 99% of the time you will only have one include entry max anyway.

5 is still present, requiring the use of / being used to allow for CIDR notation to be entered.

6 is still a WIP I hope? Assuming the checks for a proper domain name are prep for that

8 can't be tested either but I presume it's not implemented yet.
 
Some of your suggestions have been included into the latest version of the skin, please check it now :) Thank you!
 
Excellent. That does resolve most of the issues/quirks, leaving just a few cosmetic/QoL/safety changes remaining (unless there's something horribly wrong with IPv6 input).

1) In order to enter CIDR notation, you need to enter a / to force it over there. You cannot just click past the / itself to enter it.

2) The inclusion of a label for a and include at the start of input fields for Server Hostname and Include Domain to make those a bit clearer what they're for.

3) A safeguard/reminder against including more than 10 non-ip-based mechanisms. Perhaps greying out the Edit button with a tooltip for the button or a warning next to it?

4) Having text input immediately snap to a newly created field after clicking on the + symbol. When adding all of the a records to see if there was a safeguard effect in place yet, I had to manually click into the new box each time. By no means necessary but it is a nice Quality of Life change.

Edit:
It seems that there is a remaining bug/quirk for the Server Hostname/Include Domain fields. If you have two entries remaining for each and then clear out all four of them (trash can the two spares and then erase the first entry) then save the changes, it will show them as removed. If you reopen the SPF editor however, the records will come back.

This does not survive a refresh of the page so it may be some sort of caching error tied to it thinking a blank entry is an invalid domain? When I clear the initial field for Include Domain, it does pop up a warning for an invalid domain. The bug may be tied to it not properly considering a blank input field as "valid" for the sake of not entering anything?

I do see that there's two spaces in between the first IPv4 record and the mode mechanism.
 
Last edited:
It's been improved even more :) #1 would require re-coding whole input, and might add new bugs, so, was skipped for now, as in enhanced you also need to click / to enter the prefix.
 
Back
Top