Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Roland Turner via dmarc-discuss]

On 8/7/21 3:17 am, Jonathan Kamens via dmarc-discuss wrote:

It's not useful to come back and say, "Well, I mean, if they did 
things differently, then this wouldn't be an issue." They're not doing 
things differently, and they don't want to do things differently. It's 
our job to facilitate them being able to make their emails look the 
way they want to securely. It's not our job to tell them that they 
can't make their emails look the way they want to or can't employ 
third-party service providers to send out emails on behalf of their 
domains. Either of those is a non-starter. 


+1


- Roland


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Roland Turner via dmarc-discuss]

On 8/7/21 2:11 am, Alessandro Vesely via dmarc-discuss wrote:

> A mailbox provider is only one of the service providers that an organisation 
> might contract to send email on its behalf. Other common examples include:
> 
>   * Marketing automation (list management, sending mailouts, analytics)

>   * CRMs, where sellers use the CRM itself to send messages to their customers
>   * Subscription management systems that send expiry reminders
>   * Helpdesk systems that send responses to user requests
> 
> There are dozens or hundreds of less common examples.



I see.  I note that the examples you mention, except some kind of marketing,
need to receive mail, besides sending it.  Indeed, being bidirectional is a
peculiar email characteristics.  So, if a service can be integrated with a mail
system,


There's either no requirement for reception by the service provider (CRM 
case, subscription management case), or the level of "integration" is 
just an email alias (helpdesk case). Adding an account, maintaining 
credentials, etc. is implementation friction which those service 
providers avoid wherever they can.




  then it should be able to use its incoming as well as outgoing servers.


What someone/something else "should" do is not relevant in a DMARC 
discussion. The should-based engineering approaches to this problem of 
~15 years ago were difficult, contentious, and ineffective. One of key 
realisations in DMARC was that the lower the burden on domain 
registrants (i.e. the lower the adoption friction), the more widespread 
implementation will be. DMARC succeeds in large part because it avoids 
all avoidable friction for the least-engineering-savvy participants: the 
domain registrants, no matter how untidy the resulting engineering looks.


While there is some engineering appeal in the argument that you're 
making, it's overwhelmed by the importance of widespread adoption. As in 
many other contexts, systems that gain adoption are those which address 
the world as it is, not as it "should" be.




   Otherwise, it deserves using its own subdomain.


"Deserves" is even less relevant than "should". In any event, you're 
proposing exposing an implementation artefact to end-users, which is not 
even sound engineering.




Most likely, technology-impaired companies don't even host their own DNS.  The
DNS providers who do that for them should have an adequate level of expertise,
though.
...

The list of DNS providers seems to have grown quite a bit since the last time I
checked.  Freeing customers from SPF pains could be an element of distinction.


This is an interesting idea. If the market for it is real then your 
fortune awaits :-)


I would point out that DNS-content services of this type are quite rare. 
About the only mass-market examples that I can think of are:


 * DNSSEC key rotation, integrated with domain registrar services
 * DNS-based delivery optimisation (i.e. not IP anycast), integrated
   with CDNs
 * CloudFlare's proxying domain-root A records to permit aliasing the
   root while not breaking DNS (by putting CNAMEs alongside NSs, which
   they did for some time).

It's really quite rare, and generally only arises as an essential part 
of the related service. I'd hazard a guess that the amount of additional 
revenue that can be obtained through implementing and offering such 
services more generally doesn't warrant the effort.



- Roland


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[John Levine via dmarc-discuss]

It appears that Alessandro Vesely via dmarc-discuss  said:

>I see.  I note that the examples you mention, except some kind of marketing, 
>need to receive mail, besides sending it.  Indeed, being bidirectional is a 
>peculiar email characteristics.  So, if a service can be integrated with a 
>mail 
>system, then it should be able to use its incoming as well as outgoing 
>servers. 
>  Otherwise, it deserves using its own subdomain.

Sorry, but that's just silly.  Nobody ever said that inbound and outbound mail
has to take the same path.

>>> Dmarcian has a good SPF compiler already.  It is somewhat unpractical, as 
>>> you'd
>>> need to copy its result to your zone file, and repeat that operation as 
>>> often
>>> as needed.  It doesn't sound awful to call it from a cron job.
>> 
>> This is a *vastly* higher level of technical expertise than most 
>> organisations 
>> have available for this.
>
>Most likely, technology-impaired companies don't even host their own DNS.  The 
>DNS providers who do that for them should have an adequate level of expertise, 
>though.

Please excuse me while I chuckle.  You've seen how many screwed up SPF records 
there are.

Whatever the reason was to limit SPF to 10 lookups, on today's Internet there 
is no
point, and the change to increase the limit, unlike what you're proposing, is 
trivial to implement.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Jonathan Kamens via dmarc-discuss]

On 7/7/21 2:11 PM, Alessandro Vesely via dmarc-discuss wrote:

On Wed 07/Jul/2021 15:19:35 +0200 Roland Turner via dmarc-discuss wrote:
A mailbox provider is only one of the service providers that an 
organisation might contract to send email on its behalf. Other common 
examples include:


  * Marketing automation (list management, sending mailouts, analytics)
  * CRMs, where sellers use the CRM itself to send messages to their 
customers

  * Subscription management systems that send expiry reminders
  * Helpdesk systems that send responses to user requests

There are dozens or hundreds of less common examples.
I see.  I note that the examples you mention, except some kind of 
marketing, need to receive mail, besides sending it.  Indeed, being 
bidirectional is a peculiar email characteristics.  So, if a service 
can be integrated with a mail system, then it should be able to use 
its incoming as well as outgoing servers.  Otherwise, it deserves 
using its own subdomain.


Companies do not want to use subdomains in the sender addresses of any 
of the types of email listed above. They want to be able to use 
addresses in their domain, because that's what looks natural and correct 
to customers. Subdomains confuse customers, and companies do not want to 
confuse their customers.


Furthermore, the systems enumerated above do not typically use the 
domain's corporate outgoing servers. That's the whole point. They use 
their /own/ servers to send outbound emails, and that's why those emails 
need to be authenticated with either SPF or DKIM for them to pass the 
companies' DMARC policies.


You asked what the use case is. The use case was explained to you. It's 
not useful to come back and say, "Well, I mean, if they did things 
differently, then this wouldn't be an issue." They're not doing things 
differently, and they don't want to do things differently. It's our job 
to facilitate them being able to make their emails look the way they 
want to securely. It's not our job to tell them that they can't make 
their emails look the way they want to or can't employ third-party 
service providers to send out emails on behalf of their domains. Either 
of those is a non-starter.


Jonathan Kamens


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Alessandro Vesely via dmarc-discuss]

On Wed 07/Jul/2021 15:19:35 +0200 Roland Turner via dmarc-discuss wrote:

On 7/7/21 4:03 pm, Alessandro Vesely via dmarc-discuss wrote:


If I outsourced my mail to google (to stick to the example) what other
providers' SPF record do I have to include?  Oh yes, John said "to several
providers".  Why does one need more than one provider, then?


A mailbox provider is only one of the service providers that an organisation 
might contract to send email on its behalf. Other common examples include:


  * Marketing automation (list management, sending mailouts, analytics)
  * CRMs, where sellers use the CRM itself to send messages to their customers
  * Subscription management systems that send expiry reminders
  * Helpdesk systems that send responses to user requests

There are dozens or hundreds of less common examples.



I see.  I note that the examples you mention, except some kind of marketing, 
need to receive mail, besides sending it.  Indeed, being bidirectional is a 
peculiar email characteristics.  So, if a service can be integrated with a mail 
system, then it should be able to use its incoming as well as outgoing servers. 
 Otherwise, it deserves using its own subdomain.



DKIM is a more scalable approach, but it's also harder to get right initially. 
(It's extremely simple once it's working, but...)



Right, with DKIM one can use a different prefix within the same domain.



Dmarcian has a good SPF compiler already.  It is somewhat unpractical, as you'd
need to copy its result to your zone file, and repeat that operation as often
as needed.  It doesn't sound awful to call it from a cron job.


This is a *vastly* higher level of technical expertise than most organisations 
have available for this.



Most likely, technology-impaired companies don't even host their own DNS.  The 
DNS providers who do that for them should have an adequate level of expertise, 
though.




It is easier to adapt existing software to your special needs than change the
rest of the world.


The target is not limited to technical organisations who are capable of doing 
this.



The list of DNS providers seems to have grown quite a bit since the last time I 
checked.  Freeing customers from SPF pains could be an element of distinction.



Best
Ale
--


















___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Roland Turner via dmarc-discuss]

On 7/7/21 4:03 pm, Alessandro Vesely via dmarc-discuss wrote:


If I outsourced my mail to google (to stick to the example) what other
providers' SPF record do I have to include?  Oh yes, John said "to several
providers".  Why does one need more than one provider, then?


A mailbox provider is only one of the service providers that an 
organisation might contract to send email on its behalf. Other common 
examples include:


 * Marketing automation (list management, sending mailouts, analytics)
 * CRMs, where sellers use the CRM itself to send messages to their
   customers
 * Subscription management systems that send expiry reminders
 * Helpdesk systems that send responses to user requests

There are dozens or hundreds of less common examples.

DKIM is a more scalable approach, but it's also harder to get right 
initially. (It's extremely simple once it's working, but...)




Dmarcian has a good SPF compiler already.  It is somewhat unpractical, as you'd
need to copy its result to your zone file, and repeat that operation as often
as needed.  It doesn't sound awful to call it from a cron job.


This is a *vastly* higher level of technical expertise than most 
organisations have available for this.




It is easier to adapt existing software to your special needs than change the
rest of the world.


The target is not limited to technical organisations who are capable of 
doing this.



- Roland


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Alessandro Vesely via dmarc-discuss]

On Wed 07/Jul/2021 07:33:57 +0200 Roland Turner via dmarc-discuss wrote:

On 7/7/21 2:57 am, John Levine via dmarc-discuss wrote:
It appears that Alessandro Vesely via dmarc-discuss  said:
I'd suggest that a resolution to this might be to expand the finite limit (I've 
also had trouble with the 10 lookup limit, even for a small organisation), 


Why do organizations need more than 10 lookups?  Do they have a choice of 
several smart hosts?  (And the latter need, to avail of reputed smart hosts, 
keeps looking to me like a DMARC failure.)


Because they contract out their mail to several providers and include all those
providers' SPF records.  I agree that many of those providers use too many 
records
(e.g., _spf.google.com is four records that easily could have been one) but you
can't legislate being smart.

Yes, precisely that.



If I outsourced my mail to google (to stick to the example) what other 
providers' SPF record do I have to include?  Oh yes, John said "to several 
providers".  Why does one need more than one provider, then?


I understand that people have multiple email addresses each.  However, a single 
address should correspond to a single provider, no?  Do their MX also point to 
multiple providers?


How many are the domains in this state?


An "SPF compiler" could gather a ton of addresses and dynamically assign 
them to the.only.a.mechanism.U.need.example.com.


It could, but it'd be a lot easier to find the constant "10" in your SPF library
and change it to something like 50.  While you're at it, get rid of the empty
result limit which screws up IPv6 checks.


+1



+½, for the empty result limit.

Dmarcian has a good SPF compiler already.  It is somewhat unpractical, as you'd 
need to copy its result to your zone file, and repeat that operation as often 
as needed.  It doesn't sound awful to call it from a cron job.


It is easier to adapt existing software to your special needs than change the 
rest of the world.



Best
Ale
--
















___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Roland Turner via dmarc-discuss]

On 7/7/21 2:57 am, John Levine via dmarc-discuss wrote:


It appears that Alessandro Vesely via dmarc-discuss  said:
>> I'd suggest that a resolution to this might be to expand the finite limit (I've 
>> also had trouble with the 10 lookup limit, even for a small organisation), 
>
>Why do organizations need more than 10 lookups?  Do they have a choice of 
>several smart hosts?  (And the latter need, to avail of reputed smart hosts, 
>keeps looking to me like a DMARC failure.)


Because they contract out their mail to several providers and include all those
providers' SPF records.  I agree that many of those providers use too many 
records
(e.g., _spf.google.com is four records that easily could have been one) but you
can't legislate being smart.


Yes, precisely that.


>An "SPF compiler" could gather a ton of addresses and dynamically assign them 
>to the.only.a.mechanism.U.need.example.com.


It could, but it'd be a lot easier to find the constant "10" in your SPF library
and change it to something like 50.  While you're at it, get rid of the empty
result limit which screws up IPv6 checks.


+1


- Roland


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[John Levine via dmarc-discuss]

It appears that Alessandro Vesely via dmarc-discuss  said:
>> I'd suggest that a resolution to this might be to expand the finite limit 
>> (I've 
>> also had trouble with the 10 lookup limit, even for a small organisation), 
>
>Why do organizations need more than 10 lookups?  Do they have a choice of 
>several smart hosts?  (And the latter need, to avail of reputed smart hosts, 
>keeps looking to me like a DMARC failure.)

Because they contract out their mail to several providers and include all those
providers' SPF records.  I agree that many of those providers use too many 
records
(e.g., _spf.google.com is four records that easily could have been one) but you
can't legislate being smart.

>An "SPF compiler" could gather a ton of addresses and dynamically assign them 
>to the.only.a.mechanism.U.need.example.com.

It could, but it'd be a lot easier to find the constant "10" in your SPF library
and change it to something like 50.  While you're at it, get rid of the empty
result limit which screws up IPv6 checks.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Alessandro Vesely via dmarc-discuss]

On Tue 06/Jul/2021 02:55:23 +0200 Roland Turner via dmarc-discuss wrote:

On 22/5/21 7:41 am, Brandon Long via dmarc-discuss wrote:

At least at one point we definitely saw enough senders requiring too many 
lookups that we cared more about

trying to find a positive evaluation than downside from doing more.


I'd suggest that a resolution to this might be to expand the finite limit (I've 
also had trouble with the 10 lookup limit, even for a small organisation), 



Why do organizations need more than 10 lookups?  Do they have a choice of 
several smart hosts?  (And the latter need, to avail of reputed smart hosts, 
keeps looking to me like a DMARC failure.)


An "SPF compiler" could gather a ton of addresses and dynamically assign them 
to the.only.a.mechanism.U.need.example.com.



Best
Ale
--




















___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Roland Turner via dmarc-discuss]

On 22/5/21 7:41 am, Brandon Long via dmarc-discuss wrote:

I think the limits in the RFC are overly restrictive... as a receiver, 
I don't see any issue with having a
much higher limit, you waste fairly minimal resources in that 
regard... there may be an issue in the large
as a DoS type attack, but as a larger provider you might benefit more 
from weighted throttling of requests

or more general DoS-style protections.

At least at one point we definitely saw enough senders requiring too 
many lookups that we cared more about

trying to find a positive evaluation than downside from doing more.


I'd suggest that a resolution to this might be to expand the finite 
limit (I've also had trouble with the 10 lookup limit, even for a small 
organisation), rather than to burden every implementation with reliance 
upon prioritisation capability and other DoS mitigation techniques 
merely to make DMARC safe to operate.


The interests of very large receivers are particularly important of 
course, but it would appear desirable to maintain the ability for 
receivers at any size to implement.


- Roland


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Brandon Long via dmarc-discuss]

On Wed, May 19, 2021 at 1:08 PM John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> It appears that Alexander NAZARIAN via dmarc-discuss <
> alexander.nazar...@gmail.com> said:
> >So I want to understand whether having MX placed in the beginning of SPF
> >record can cause a quicker reach of '10 DNS lookup limitation' for G Suite
> >senders, due to the reason that G Suite has 5 MX records (and I assume
> that
> >number of DNS queries, executed to resolve MXes to IPs, is 6 and not 1)
>
> I think he already answered that question. Different implementations
> of SPF interpret the counting rule differently, so if you want your
> mail delivered, assume that they will use the largest count. If you
> are checking else's mail, use the smallest count. This is the well
> known robustness principle about interpreting ambiguous specs.
>
> This particular case has not come up in the past because, in practice,
> the only sites that use "mx" are tiny sites with a single mail host
> with a single address. It doesn't make a lot of sense for secondary MX
> hosts to be sending mail for someone's domain.
>
> I also think that some of the advice about limits in 7208 is not very
> good.  For example.
> you are likely to get different NOERROR counts evalating an ipv4 address
> than evaluating
> an ipv6 addresss since there are lots of hosts with A records but no .
>

I think the limits in the RFC are overly restrictive... as a receiver, I
don't see any issue with having a
much higher limit, you waste fairly minimal resources in that regard...
there may be an issue in the large
as a DoS type attack, but as a larger provider you might benefit more from
weighted throttling of requests
or more general DoS-style protections.

At least at one point we definitely saw enough senders requiring too many
lookups that we cared more about
trying to find a positive evaluation than downside from doing more.

Brandon
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[John Levine via dmarc-discuss]

It appears that Alexander NAZARIAN via dmarc-discuss 
 said:
>So I want to understand whether having MX placed in the beginning of SPF
>record can cause a quicker reach of '10 DNS lookup limitation' for G Suite
>senders, due to the reason that G Suite has 5 MX records (and I assume that
>number of DNS queries, executed to resolve MXes to IPs, is 6 and not 1)

I think he already answered that question. Different implementations
of SPF interpret the counting rule differently, so if you want your
mail delivered, assume that they will use the largest count. If you
are checking else's mail, use the smallest count. This is the well
known robustness principle about interpreting ambiguous specs.

This particular case has not come up in the past because, in practice,
the only sites that use "mx" are tiny sites with a single mail host
with a single address. It doesn't make a lot of sense for secondary MX
hosts to be sending mail for someone's domain.

I also think that some of the advice about limits in 7208 is not very good.  
For example.
you are likely to get different NOERROR counts evalating an ipv4 address than 
evaluating
an ipv6 addresss since there are lots of hosts with A records but no .

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[Matthäus Wander via dmarc-discuss]

Alexander NAZARIAN via dmarc-discuss wrote on 2021-05-18 20:40:

Different online SPF checkers show different results.


> [...]
>
So, looks that mailbox providers count MX mechanism as 1 lookup (no 
matter how many hostnames MX record resolves to) and dmarcanalyzer.com 
 tool lookup check have nothing with reality,


Could you help with understanding how many DNS queries are being run for 
the MX mechanism ?


You've shown two different interpretations of the SPF specification. To 
me, which of these is the correct interpretation is of less importance 
than the fact that both interpretations exist. If high deliverability is 
desired, it's thus wise to comply with the more strict interpretation.


In the concrete example, the "mx" mechanism is redundant to 
"include:_spf.google.com" and can be omitted.


Regards,
Matt
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)