In <p06110402bd3ee0b26466(_at_)[129(_dot_)46(_dot_)227(_dot_)161]> Ted Hardie
<hardie(_at_)qualcomm(_dot_)com> writes:
2) Meng, and many others, have pointed out that in the vast majority
of cases, the information *will* be the same and changing the
version number will cause far more problems than it solves.
I don't think so. They have tried to say "the answer to the two
questions would be the same", which is not the same as
"the information will be the same". The answer to the question
"What is the last name of the current occupant of the U.S.
presidency?" and "What is the last name of the artist whose
debut album was 'The Kick Inside'?" may be the same,
but Bush, George W. and Bush, Kate are not the same.
I can appreciate your comparisons of the same IP address showing up in
an MX and NS record and the above anlogy about two people with the
same last name of Bush. You are trying to draw a shart distinction
between the questions and the answers.
The thing is that the two MARID questions being ask are:
1) Is it valid for this IP address send an email with a MAIL FROM
and/or HELO claiming from being from the given domain? (SPF-classic)
2) Is it valid for this IP address send an email with a From: header
claiming from being from the given domain? (SenderID)
These questions are much more closely related than NS or MX records.
To use your analogy, it is like asking these two questions about the
president:
a) Is the current occupant of the U.S. Presidency over the age of 35?
b) Is the current occupant of the U.S. Presidency a U.S. citizen?
The answer two these two questions is "yes" for all U.S. Presidents
that have ever been and will likely to ever be. This is not just
because of some cosmic coincidence, but because these two questions
have a common root in the requirements of being a U.S. President.
Similarly, the answer to the two MARID questions are also almost
always the same because of common roots.
Understanding the common roots leads to a deeper understanding of what
we are doing. Understanding what the co-chairs have said we will try
to address in the foreseeable future make finding this deeper
understanding very relavant to what we are doing today.
As far as cosmic coincidences go, I suspect many people can guess the
answers to the following questions:
1) Which week did the warranty of my laptop run out?
2) Which week did my laptop die?
3) Which week did I really need to post a bunch of stuff to MARID list
about the current I-Ds, but is sitting on a dead laptop?
*heavy sigh* (Yes, I have backups. No, backups are not an easy
replacement.)
In another message:
In
<Pine(_dot_)LNX(_dot_)4(_dot_)51(_dot_)0408101450430(_dot_)24973(_at_)snoopy(_dot_)smi(_dot_)sendmail(_dot_)com>
Rand Wacker <rand(_at_)sendmail(_dot_)com> writes:
Forgive me if this snake has been addressed before, but at the WG meeting
last week it seemed to be slightly different. According to both folks
From Cisco and the in-house DNS experts I've asked, I believe that if you
put in multiple TXT records for the same FQDN (example.com as above), then
*all* of those TXT records are sent back in a single UDP reply packet, so
the 512 (more like 420) byte UDP packet restriction applies to THE
AGGREGATE SIZE of ALL text records for a single FQDN.
Yes, is a well known issue and one of the goals of SPF was to make
records as small as practical.
While the above example may be reasonably small, AOL's current SPF record
is pushing 170 bytes, which would limit them to publishing only three
concurrent records in the same FQDN space.
AOL is not the largest SPF record I found when doing the surveys of
1.3 million email domains, but it is certainly one of the largest.
Even so, AOL can fit two SPF-like record into a UDP DNS packet.
Meng et al worked hard to make the print of SPF records small, and
first thing the IETF doing doubling the space used.
I believe that the working group made no objection to sub-domaining
records (publishing TXT in _marid.example.com), so if we go down the path
of changing the version number or even the format we should take that in
to consideration.
Publishing into a sub-domain doesn't really help if this working group
is going to turn about and create more records for 2821 identities.
Changing just the version number of SPF records is bad engineering,
bad for maintenance, creates confusion, and is short-sighted.
-wayne