I can confirm that his console is NOT corrupt. The same exact thing is
happening with me.

I am unable to publish a single-line SPF record as it is too long. You
can copy and paste and, yet is gets the scroll bar at the bottom and
looks like it is going to work perfectly, BUT once you save it, close
it and reopen it IT IS TRUNCATED EVERY TIME. Nice feature. This goes
for Windows 2000 or Windows 2003 (with or without SP1).

Looks like we are stuck with multiple records and multiple "includes"
to get this thing working.

"you would think someone would actually test this stuff before rolling
it out"

In news:1141242510.442963.132960@v46g2000cwv.googlegr oups.com,
Carl R <carlrimmel@gmail.com> stated, which I commented on below:
> I can confirm that his console is NOT corrupt. The same exact thing
> is happening with me.
>
> I am unable to publish a single-line SPF record as it is too long.
> You can copy and paste and, yet is gets the scroll bar at the bottom
> and looks like it is going to work perfectly, BUT once you save it,
> close it and reopen it IT IS TRUNCATED EVERY TIME. Nice feature.
> This goes for Windows 2000 or Windows 2003 (with or without SP1).
>
> Looks like we are stuck with multiple records and multiple "includes"
> to get this thing working.
>
> "you would think someone would actually test this stuff before rolling
> it out"

Can you email the file in txt format, please? I would like to test it with
your data.

Thanks,
Ace

Carl R wrote:
> I can confirm that his console is NOT corrupt. The same exact thing
> is happening with me.
>
> I am unable to publish a single-line SPF record as it is too long.
> You can copy and paste and, yet is gets the scroll bar at the bottom
> and looks like it is going to work perfectly, BUT once you save it,
> close it and reopen it IT IS TRUNCATED EVERY TIME. Nice feature.
> This goes for Windows 2000 or Windows 2003 (with or without SP1).
>
> Looks like we are stuck with multiple records and multiple "includes"
> to get this thing working.
>
> "you would think someone would actually test this stuff before rolling
> it out"

Actually, I have not been able to recreate this behavior on any of my DNS
servers, regardless of OS. The closest I can get is trying to look at the
SPF record on a secondary zone, which disabled the scroll bar. That did not
prevent the secondary from returning the full data of the SPF record.

--
Best regards,
Kevin D. Goodknecht Sr. [MVP]
Hope This s
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
http://support.wftx.us/
https://secure.lsaol.com/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oe.com/OEBackup/Default.aspx
===================================

In news:ezVWfjfPGHA.3164@TK2MSFTNGP11.phx.gbl,
Kevin D. Goodknecht Sr. [MVP] <admin@nospam.WFTX.US> stated, which I
commented on below:
> Actually, I have not been able to recreate this behavior on any of my
> DNS servers, regardless of OS. The closest I can get is trying to
> look at the SPF record on a secondary zone, which disabled the scroll
> bar. That did not prevent the secondary from returning the full data
> of the SPF record.

Same here. I couldn't reproduce it either. That's why I wanted a copy of
Brad and Carl's data to test it out and see what's up. Maybe it's something
so simple we're overlooking.

Ace

In news:1141242510.442963.132960@v46g2000cwv.googlegr oups.com,
Carl R <carlrimmel@gmail.com> stated, which I commented on below:
> I can confirm that his console is NOT corrupt. The same exact thing
> is happening with me.
>
> I am unable to publish a single-line SPF record as it is too long.
> You can copy and paste and, yet is gets the scroll bar at the bottom
> and looks like it is going to work perfectly, BUT once you save it,
> close it and reopen it IT IS TRUNCATED EVERY TIME. Nice feature.
> This goes for Windows 2000 or Windows 2003 (with or without SP1).
>
> Looks like we are stuck with multiple records and multiple "includes"
> to get this thing working.
>
> "you would think someone would actually test this stuff before rolling
> it out"

Ok, you got my curiosity. I tried testing it with a large set of data,
specifically text I copied from a website and pasted it into word, got a
character count, 1562 (with spaces), and pasted it into a TXT record. It
truncated it to 251. So I thought let me remove all the spaces out of the
text passage that I copied. I got 1061 characters. I copied and pasted that
text without spaces, into the TXT record, and it truncated it to 56.

Hmm... So then in Word, I dropped the character count to 255 without spaces.
I copied and pasted that, and it WORKED. I added one more character, and it
truncated it. I tried it again and it deleted the record completely. I tried
it again, and it truncated it to 33 characters. Hmm, interesting. So if it
is longer than 255, it is will not take it and the system acts up on it.
Hmm. Now I know many records types, commands, such as SMTP commands, and
others, have a maximum length of 255, for that's the buffer size. Any
attempt to jam more than that is considered a buffer overflow.

So gouing on the 255 assumption and the system was trying to protect itself
and/or just follow the RFC, at the same time not bashing myself over the
head trying to say the operating system is nuts, or blaming Microsoft for
that matter, as you implied in your post, I did some research.

I found RFC 1035. I defines DNS RR types, but it didn't specifically mention
length about any specific record, but it did say a "Name" can only be 255.
The text data in a TXT is a "name" by it's definition, as I read from the
article and noted below from RFC 1035:
http://www.faqs.org/rfcs/rfc1035.html

=====================
2.3.4. Size limits

Various objects and parameters in the DNS have size limits. They are
listed below. Some could be easily changed, others are more
fundamental.

labels 63 octets or less

names 255 octets or less

TTL positive values of a signed 32 bit number.

UDP messages 512 octets or less
=====================


John had a point earlier on about keeping response records less than 512,
but that would be the total response of a query, meaning, if a query was for
an MX record, all the MX records for a zone will be returned. Hotmail and
Yahoo have over 512 in the response, but each record is barely a line long.
In this case, the TXT record is just that, a record, and has limitations
based on the RFC.

So, I would not bash Microsoft about this because they're just following the
RFCs, as are other DNS vendors. So I think you were a little quick to point
fingers without doing a little simple research on it to prove/disprove it.

Ace

"Ace Fekay [MVP]"
<PleaseSubstituteMyActualFirstName&LastNameHere@ho tmail.com> wrote in
message news:OQ2ReKoPGHA.2912@tk2msftngp13.phx.gbl...
> In news:1141242510.442963.132960@v46g2000cwv.googlegr oups.com,
> Carl R <carlrimmel@gmail.com> stated, which I commented on below:
> I found RFC 1035. I defines DNS RR types, but it didn't specifically
> mention length about any specific record, but it did say a "Name" can only
> be 255. The text data in a TXT is a "name" by it's definition, as I read
> from the article and noted below from RFC 1035:
> http://www.faqs.org/rfcs/rfc1035.html
>

Maybe I can .

If you write a TXT record (for SPF etc) that is too long
(and I forget the actual limit but generally make it fit
in the dialog width and you are ok) then you WILL get
truncated behavior -- if not in the console itself, in the
return value to client requests.

IF HOWEVER you (artificially) use your own line
breaks it seems to work for most all purposes.

There are also absolute limits beyond which at least
some clients and SPF processing software (that is
common) will blow up on your records.

The following (rather long) record works -- it is
LITERALLY 5 lines as shown:

v=spf1 ip4:64.202.167.0/24 ip4:64.202.189.0/24
ip4:64.202.166.0/24 ip4:64.202.165.0/24 ip4:64.202.163.0/24
ip4:68.178.144.60/31 include:in.spf.secureserver.net
include:spf.learnquick.com include:deleted.com
include:ak.learnquick.com ip4:68.178.144.167 -all

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

> =====================
> 2.3.4. Size limits
>
> Various objects and parameters in the DNS have size limits. They are
> listed below. Some could be easily changed, others are more
> fundamental.
>
> labels 63 octets or less
>
> names 255 octets or less
>
> TTL positive values of a signed 32 bit number.
>
> UDP messages 512 octets or less
> =====================
>
>
> John had a point earlier on about keeping response records less than 512,
> but that would be the total response of a query, meaning, if a query was
> for an MX record, all the MX records for a zone will be returned. Hotmail
> and Yahoo have over 512 in the response, but each record is barely a line
> long. In this case, the TXT record is just that, a record, and has
> limitations based on the RFC.
>
> So, I would not bash Microsoft about this because they're just following
> the RFCs, as are other DNS vendors. So I think you were a little quick to
> point fingers without doing a little simple research on it to
> prove/disprove it.
>
> Ace
>

In news:OnRS6cVZGHA.4248@TK2MSFTNGP05.phx.gbl,
Herb Martin <news@LearnQuick.com> stated, which I commented on below:

> Maybe I can .
>
> If you write a TXT record (for SPF etc) that is too long
> (and I forget the actual limit but generally make it fit
> in the dialog width and you are ok) then you WILL get
> truncated behavior -- if not in the console itself, in the
> return value to client requests.
>
> IF HOWEVER you (artificially) use your own line
> breaks it seems to work for most all purposes.
>
> There are also absolute limits beyond which at least
> some clients and SPF processing software (that is
> common) will blow up on your records.
>
> The following (rather long) record works -- it is
> LITERALLY 5 lines as shown:
>
> v=spf1 ip4:64.202.167.0/24 ip4:64.202.189.0/24
> ip4:64.202.166.0/24 ip4:64.202.165.0/24 ip4:64.202.163.0/24
> ip4:68.178.144.60/31 include:in.spf.secureserver.net
> include:spf.learnquick.com include:deleted.com
> include:ak.learnquick.com ip4:68.178.144.167 -all

I checked your txt record. But didn't count the characters. Was that more
than 512 bytes?

I know this is a month and a half from the original post, and probably the
original poster has long forgotten it, but have you tried it with 1000
characters?

Ace

> I know this is a month and a half from the original post, and probably the
> original poster has long forgotten it, but have you tried it with 1000
> characters?
>

If I remember correctly, I ran into trouble with
the (common) SPF checkers. It's usually more
about complexity than actual length (again IIRC)
though.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Ace Fekay [MVP]" <PleaseAskMe@SomeDomain.com> wrote in message
news:uV4rBFkZGHA.4424@TK2MSFTNGP05.phx.gbl...
> In news:OnRS6cVZGHA.4248@TK2MSFTNGP05.phx.gbl,
> Herb Martin <news@LearnQuick.com> stated, which I commented on below:
>
>> Maybe I can .
>>
>> If you write a TXT record (for SPF etc) that is too long
>> (and I forget the actual limit but generally make it fit
>> in the dialog width and you are ok) then you WILL get
>> truncated behavior -- if not in the console itself, in the
>> return value to client requests.
>>
>> IF HOWEVER you (artificially) use your own line
>> breaks it seems to work for most all purposes.
>>
>> There are also absolute limits beyond which at least
>> some clients and SPF processing software (that is
>> common) will blow up on your records.
>>
>> The following (rather long) record works -- it is
>> LITERALLY 5 lines as shown:
>>
>> v=spf1 ip4:64.202.167.0/24 ip4:64.202.189.0/24
>> ip4:64.202.166.0/24 ip4:64.202.165.0/24 ip4:64.202.163.0/24
>> ip4:68.178.144.60/31 include:in.spf.secureserver.net
>> include:spf.learnquick.com include:deleted.com
>> include:ak.learnquick.com ip4:68.178.144.167 -all
>
> I checked your txt record. But didn't count the characters. Was that more
> than 512 bytes?
>
> I know this is a month and a half from the original post, and probably the
> original poster has long forgotten it, but have you tried it with 1000
> characters?
>
> Ace
>

In news:OPMxHWmZGHA.1204@TK2MSFTNGP04.phx.gbl,
Herb Martin <news@LearnQuick.com> stated, which I commented on below:
>> I know this is a month and a half from the original post, and
>> probably the original poster has long forgotten it, but have you
>> tried it with 1000 characters?
>>
>
> If I remember correctly, I ran into trouble with
> the (common) SPF checkers. It's usually more
> about complexity than actual length (again IIRC)
> though.

Hmm, complexity in the number and/or type of text?