[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: consensus call of RR prefix
Also I would like to add that I support having common "mail policy" prefix
for SPF RR type refords as well. As with arguments for option2, this helps
with wildcards (no extra duplicate entries) and it allows to in the future
extend use of SPF to be general policy language for other protocols but
would avoid collision with existing mail policy base (except in case of
wildcards, but there redirection can be used if records get too large
all together). So in this case, we need to use protocol specific name
as part of prefix, something like:
_smtp.example.com. IN TXT "spf2.0/pra,mfrom ..."
_smtp.example.com. IN SPF "spf2.0/pra,mfrom ..."
Or possibly:
_smtp._spf.example.com. IN TXT "spf2.0/pra,mfrom ..."
_smtp.example.com. IN SPF "spf2.0/pra,mfrom ..."
On Sat, 4 Sep 2004, william(at)elan.net wrote:
> On Fri, 3 Sep 2004, Andrew Newton wrote:
>
> > From the discussion on prefixes for the DNS record, there seems to have
> > been no discernible outcome regarding the use of prefixes for the
> > purposes of avoiding collisions with other DNS records (thus avoiding
> > fallback to DNS over TCP).
> >
> > Naturally, this issue wraps itself into both the versioning/scoping
> > issue and the wildcard issue. Based on the comments received so far,
> > it is the opinion of the co-chairs that there is no consensus on how to
> > handle wildcards and that most participants seem to agree that
> > wildcards present a problem no matter the solution. Based on the
> > comments received so far, it is the opinion of the co-chairs that there
> > is consensus on placing the "scope" in the RDATA of the record and no
> > consensus on the scope being in the prefix.
> >
> > Therefore, that leaves one under-discussed question: should a prefix be
> > used to avoid collision with other records as one measure of preventing
> > the requirement of DNS over TCP?
>
> I'm not very strongly in favor or against using dns prefixes for TXT record
> placement (my preference as indicated at the very end of message and it
> depends on other factors), but I'd like to summarize current arguments
> and points for and against using subdomain prefixes and explain how it
> all works so that others that are new to this can decide on their own.
>
> As a reminder, in these posts:
> http://www.imc.org/ietf-mxcomp/mail-archive/msg03726.html
> http://www.imc.org/ietf-mxcomp/mail-archive/msg03762.html
> I sucessfully argued that because of how wildcards work (or don't work :)
> scoping can not rely on prefixes alone and version and scope must be part
> of data portion (this chairs agree with as per their statemenet above).
>
> It can be noted that original thread discussion about using or not using
> prefixes started from problems that may exist when user does want to publish
> two types of SPF records (with presumably different version strings), like:
> (*1*) example.com. IN TXT "v=spf1 ..."
> example.com. IN TXT "spf2.0/pra ..."
>
> ------------------------------
> Option1
> ------------------------------
>
> Since total size of RDATA space in udp dns packet is limited to approximately
> 480 bytes, each of the records from (*1*) would have to be smaller and be
> half that (up to say max 200 bytes to be safe), it has been said that is
> too small and hence using dns prefixes/subdomains was proposed, like:
> (*2*) _mfrom._rmx.example.com. IN TXT "v=spf1 ..."
> _pra._rmx.example.com. IN TXT "spf2.0/pra ..."
>
> However same wildcard problem I have pointed out applies here, names that
> in case of wildcards, no matter if there are prefixes or not, you would
> have to put wildcard records in the root of the domain and thus have
> this limitation with size of records:
> (*3*) *.example.com. IN TXT "v=spf1 ..."
> *.example.com. IN TXT "spf2.0/pra ..."
>
> But as has been pointed out to me by David Blacka, that prefixes dont work
> with specific case of wildcards, doesnt mean its bad for everyone else
> and use of wildcards is in general pretty rare, so we should not discard
> usefullness of scenario (*2*) just because of wildcards.
>
> I agreed with that in this message:
> http://www.imc.org/ietf-mxcomp/mail-archive/msg03963.html
> But have pointed out that there is another problem that we may have and
> that has to do with number of dns requests. In case like (*1*) when all
> SPF records are located in the root of zone, in order to see all the
> mail policies for different identities/scopes. a verification client
> program would only need to make one dns request for TXT record under that
> domain. But if we go with different prefixes for each scope as with (*2*),
> then client program would have to normally make two dns requests for each
> of those identities (i.e. for _pra._rmx and for _mfrom._rmx).
>
> It can be noted that if identities have the same SPF record (and Mark
> Lentczner has pointed out that for most situations SenderID/PRA and
> SPF-Classic/Mail-From records are likely to be the same) then we maybe
> able to deal with this by having records like:
> (*4*) _mfrom._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24
> _pra._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24
>
> In that case a program looking pra or mailfrom identity scoping record
> (which it does first does not matter if records are the same) would
> get the record indicating that the other identity is equivalent and would
> presumably not have to do an extra dns lookup. However this does lead to
> situation of having to enter and maintain two different but completely
> equivalent (as far as RDATA) TXT records.
>
> I'll note that to support programs checking SPFv1 records, additional record
> may have to be added (also equivalent), so we would have:
> (*5*) _mfrom._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24
> _pra._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24
> example.com. IN TXT "v=spf1 ip4:10.0.0.0/24 ~all"
>
> ------------------------------
> Option2
> ------------------------------
>
> Another option maybe to place SPF TXT records in the same prefix no matter
> what identity/scope this is, which allows to avoid collision with other
> TXT records that may exist for the domain/host:
> (*6*) _rmx.example.com. IN TXT "spf2.0/mfrom ..."
> _rmx.example.com. IN TXT "spf2.0/pra ..."
>
> In that case it is not necessary to make an extra dns lookups for multiple
> identity records, nor is it necessary to have two separate records when
> they are the same, as the following will work just fine:
> _rmx.example.com. IN TXT "spf2.0/pra,mfrom ..."
>
> However, this does mean that in case the two records are seriously different
> size limitations would apply (since records share the same prefix) and records
> would have to be limited to half of what they could have been. Solution
> to this involves doing redirection, which would lead to 2nd dns lookup:
> (*7*) _rmx.example.com. IN TXT "spf2.0/pra redirect=_pra._rmx.example.com
> _rmx.example.com. IN TXT "spf2.0/mfrom redirect=_mfrom._rmx.example.com
> _pra._rmx.example.com. IN TXT "spf2.0/pra ...."
> _pra._mfrom.example.com. IN TXT "spf2.0/pra ...."
>
> Additionally I'll note that there exist another possible plus side that
> applies to how wildcards are entered. Because of how wildcards work normally
> you need to have two separate records when using wildcards - one for domain
> itself and one wildcard for all subdomains:
> (*8*) example.com. IN TXT "v=spf1 ..."
> example.com. IN TXT "spf2.0/pra ..."
> *.example.com. IN TXT "v=spf1 ..."
> *.example.com. IN TXT "spf2.0/pra ..."
> In above the first two records apply to example.com itself while the 2nd
> two apply to any subdomain under it (i.e. xxxx.example.com or even futher
> down the tree like a.b.c.example.com) and normally these two would be the
> same, but entering wildcard seems to lead to duplicate entries.
>
> But when using prefixes (and this applies to option 1 as well), we only need
> to have one record:
> (*9*) *.example.com. IN TXT "v=spf1 ..."
> *.example.com. IN TXT "spf2.0/pra ..."
>
> And this record would equially apply to both _rmx.example.com and to
> _rmx.xxx.example.com or to _rmx.a.b.c.example.com, etc.
>
> ------------------------------
> Summary
> ------------------------------
>
> So we have several options:
> Option1 is using prefixes with different one for each scope/identity
> Option2 is using prefixes but with same prefix no matter what spf scope
> Option3 is not using prefixes at all (SPF2 TXT record in zone root)
> Option4 is not using prefixes, nor even using new SPF2 version (in that
> case scoping is achieved by using scope modifier with v=SPF1 record)
>
> For Option1 the PROs are:
> 1. Avoids collision with other TXT records for domain
> 2. Avoids collision with different TXT records (except for wildcards)
> and thus avoids record size limit for different spf scope records
> 3. Allows to specify wildcard entry for subdomain & domain using one record
> The CONs are:
> 1. Requires multiple dns lookups if SPF records for different scopes
> are different (no matter what size these records are)
> 2. Requires multiple dns records if SPF records for different scopes
> are the same (no matter what size these records are)
> 3. Requires separate SPFv1 records and dns lookup to support existing
> SPVv1 resolvers and libraries
>
> For Option2 the PROs are:
> 1. Avoids collision with other TXT records for domain
> 2. Allows to specify wildcard entry for subdomain & domain using one record
> 3. Allows to specify multiple scopes together in one record when they are same
> 4. Does not require separate dns lookups for different scope records no
> matter if they are different or the same
> The CONs are:
> 1. Requires multuple dns lookups to avoid size limitations if multiple
> scope SPF records are different and are large
> 2. Requires separate SPFv1 records and dns lookup to support existing
> SPVv1 resolvers and libraries
>
> For Option3 the PROs are:
> 1. Allows to specify multiple scopes together in one record when they are same
> 2. Does not require separate dns lookups for different scope records no
> matter if they are different or the same
> 3. Does not require separate dns lookups for SPFv1 records
> (but normally you would not need to do it anyway)
> The CONs are:
> 1. Collision problems with other (non-SPF) TXT records for the domain
> 2. Requires multuple dns lookups to avoid size limitations if multiple
> scope SPF records are different and are large
> 3. Requires multiple records to specify wildcard for domain & subdomains
> 3. Requires separate SPFv1 records and dns lookup to support existing
> SPFv1 libraries and resolvers
>
> For Option4 the PROs are:
> 1. Allows to specify multiple scopes together in one record when they are same
> 2. Does not require separate dns lookups for different scope records no
> matter if they are different or the same
> 3. Does not require separate dns lookups for SPFv1 records and fully
> supports existing SPVv1 libraries and resolvers with one record
> The CONs are:
> 1. Collision problems with other (non-SPF) TXT records for the domain
> 2. Requires multuple dns lookups to avoid size limitations if multiple
> scope SPF records are different and are large (*)
> 3. Requires multiple records to specify wildcard for domain & subdomains
>
> (*) I note that when using scoping modifier, different scope records can
> have shared data parts all in one SPF record and this allows for smaller
> size of records and avoids size limitations and necessity to do 2nd
> dns lookup in majority of situations. For more info see:
> http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html
> http://www.imc.org/ietf-mxcomp/mail-archive/msg03716.html
> http://www.imc.org/ietf-mxcomp/mail-archive/msg03731.html
>
> ------------------------------
>
> In my opinion a lot depends on if we consider supporting existing installed
> SPF v1 base important or not and consider that people using existing libraries
> and publishing spfv1 records can upgrade quickly to new spf2 records or not.
>
> If we do want to support SPFv1 base as much as possible and think that new
> scope for mailfrom will be deployed along with SPF1 records (and hence
> programs like spamassasin would do lookups for both for considerable time),
> then option4 is the best one and completely avoids these issues.
>
> On the other hand if we think that transition to SPF2 records would be quick
> and nobody would do SPF1 lookups in say one year time, then to me option2
> (common prefix for all spf records) looks like the best one because compared
> to option3 (no prefixes) it has the following advantages:
> 1. Avoids collision with other TXT record for domain
> 2. Allows to specify wildcard entry for subdomain & domain using one record
> As far as everything else it is pretty much same as option3, with exception
> that possibly some bad dns gui programs do not allow to enter "_" records
> (but all dns servers support this just fine).
>
> And in my opinion option1 (separate prefixes for different scopes) is the
> worst one because it leads to either multiple dns records or multiple
> dns lookups and those exist no matter if record is large or small and so
> would effect absolutely everybody.
>
> > Incidentally, the co-chairs note that many examples of the prefix have
> > used "-marid". We would note that "MARID" is the name of this working
> > group and likely not meaningful beyond the context of discussions and
> > process of this working group. Therefore we recommend a more
> > meaningful label such as "_rmx": the deduction of its meaning is easier
> > and it references the genesis of the MARID idea.
>
> I have no strong preference as far as prefix name, but I would like to
> note that _rmx has meaning if we're talking about MAIL-FROM identity
> SPF scope records but in general SPF records might apply to different
> identities (for example PTR scope from unified SPF) and might not not be
> related to mail-from or RMX at all. So I think general prefix such
> as _spf might be better. But I have complied with chair's request and
> have used _rmx in all above examples.
>
> ---
> William Leibzon, Elan Networks:
> mailto: william@xxxxxxxx
> Anti-Spam Research Worksite:
> http://www.elan.net/~william/asrg/