Merge of SPF-record

[pawel-kow]

Merge of SPF-record

[arnoldblinn]

Seems to me that sometimes people would want some sort of merge and sometimes not. When would Domain Connect know to “merge” vs. “nuke”? From: Pawel Kowalik <[email protected]> Sent: Wednesday, May 2, 2018 6:01 AM To: Domain-Connect/spec <[email protected]> Cc: Subscribed <[email protected]> Subject: [Domain-Connect/spec] Merge of SPF-record (#10) Imagine there are 2 services configured for one domain, which both can send E-mail from the accounts assigned to the domain name. Typical setup: 1. Mail service: template with MX and SPF records 2. Newletter service: template with SPF and DKIM configuration Current conflict resolution in the spec advises to remove service (1) in case service (2) is configured. This is probably not the intended usage by the customer. Other option, not to detect conflict will result in 2 SPF records -> broken setup, not conform to RFC (https://tools.ietf.org/html/rfc4408#section-3.1.2<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4408%23section-3.1.2&data=02%7C01%7C%7C6da2123b825c45af8e5308d5b02cc92b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636608628788323730&sdata=5IRQLyJH%2B84OtpqC3T%2Fm4CI1BBfmXvrsCzv1IcAmnoE%3D&reserved=0>) Similar, if SPF records would be marked as not-essential (see PR #9<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2Fspec%2Fpull%2F9&data=02%7C01%7C%7C6da2123b825c45af8e5308d5b02cc92b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636608628788323730&sdata=H9NYXEpF0niC8JVhU1XVmCVwM7X1HitFF3tANBhm0lA%3D&reserved=0>) it will not brake service (1) but will also only make one of 2 services not failing on SPF-checks. I think the only viable solution is to define SPF-merge into the standard and define the strategy. My proposal would be: Merge everything between "v=spf1" and "all". Chose the highest value for "all" (so from ~all and -all the merged version would show -all). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2Fspec%2Fissues%2F10&data=02%7C01%7C%7C6da2123b825c45af8e5308d5b02cc92b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636608628788479982&sdata=5xIsHoc0IAaYXiQ2QGL2RRggZbb4%2FVDJ9%2BcIdWUlV%2Fs%3D&reserved=0>, or mute the thread<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIxhvLyeUb1O9luWVUP517xFz3pWTUHWks5tua4ZgaJpZM4Tvaes&data=02%7C01%7C%7C6da2123b825c45af8e5308d5b02cc92b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636608628792230070&sdata=cY9i%2BwbGHH1lzxD3YTGb9bYAIvX0GhXc4Q1ZP9OriPo%3D&reserved=0>.

[pawel-kow]

Any use case where Domain Connect shall nuke the template solely based on SPF?

[pawel-kow]

I propose simple merging logic. I checked it in the mean time with Mailjet, who implement such logic on their side this way:

• take “v=spf1” static prefix
• for all services with SPF record
  o add all the rules to the result in the same order, excluding “all” rule
• add “all” rule, taking the least (or most tbd) restrictive of “all” rules between the merged templates

If DNS provider supports also “reverse” use-case (explicit or by conflict management) it should also then merge the record again from the remaining templates.

I think also we should go into direction of advising generally SPF records as removable (essential = OnApply), so that in critical cases when the record gets too long or gets too many DNS lookups (standard defines 10) the customer could fix it without dropping all related templates from DNS.

@arnoldblinn , @FlorentinStafie would love to know your opinion/remarks so I can draft the change to the spec.

[FlorentinStafie]

Trying again in case my previous reply was lost. Pawel, While I brush up on my SPF knowledge can you comment on the followings: 1. Why would we not stick to the current implementation of asking customer for consent to overwrite the Office 365 records? Why not ask these customers to edit this record in the domain control panel manually. 2. SPF is about protection and thus the most common sense choice for which mechanism to apply is the most restrictive one. Herein lies the conundrum. I am concerned that no matter which choice we make there will not be one that applies to a majority. Thus is better to ask these customers to make the edits themselves in domain control panel. If you still want to pursue this path I would suggest one improvement (at least I consider it as such) – in the consent dialog add an option for customers to edit the merged result before applying the SPF record. From: Pawel Kowalik <[email protected]> Sent: May 14, 2018 2:58 AM To: Domain-Connect/spec <[email protected]> Cc: Florentin Stafie <[email protected]>; Mention <[email protected]> Subject: Re: [Domain-Connect/spec] Merge of SPF-record (#10) I propose simple merging logic. I checked it in the mean time with Mailjet, who implement such logic on their side this way: * take “v=spf1” static prefix * for all services with SPF record o add all the rules to the result in the same order, excluding “all” rule * add “all” rule, taking the least (or most tbd) restrictive of “all” rules between the merged templates If DNS provider supports also “reverse” use-case (explicit or by conflict management) it should also then merge the record again from the remaining templates. I think also we should go into direction of advising generally SPF records as removable (essential = OnApply), so that in critical cases when the record gets too long or gets too many DNS lookups (standard defines 10) the customer could fix it without dropping all related templates from DNS. @arnoldblinn<https://github.com/arnoldblinn> , @FlorentinStafie<https://github.com/FlorentinStafie> would love to know your opinion/remarks so I can draft the change to the spec. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ac1z5OtfB2mmqXZY1EJtzCDNBwN75ln4ks5tyVUKgaJpZM4Tvaes>.

[arnoldblinn]

I actually like the idea. I would go with the least restrictive all clause, but the realitiy is that anyone who doesn't do a -all is asking for trouble.

The problem with your alternative Florentin is that you are basically saying "punt". Telling a novice user to manually edit an SPF you might as well throw them in the water with chum and great white sharks. Users don't understand SPF. Even I didn't till like five minutes

[pawel-kow]

Just re-opening to keep open until final wording lands in the spec.

@FlorentinStafie, just 2 comments on your questions
Re 1) Current implementation does not override, as it detect conflict -> in result one of the templates will stay the other will be removed as whole (template consistency principle we follow)
Overwrite is also not good as then only one of 2 providers will be able to send E-mails

Re 2) I could find arguments in both directions. If any of providers define ? or ~ rule, it means he had a reason for that (as mentioned by @arnoldblinn is asking for trouble, but SPF is in some areas so dark that I don't dare to claim I know all corner cases). In this sense "upgrading" his rule to - may mean that these E-mails are not delivered and this service is affected. "Least restrictive" would offer less protection but is likely to cause less issues.

I think manual intervention on an SPF, by removing rules of one of service providers shall be explicitly allowed by him (using essential = OnApply), otherwise following again template consistency principle I would not offer it.