SPF Records

  • Thread starter Thread starter Brad Baker
  • Start date Start date
B

Brad Baker

I am trying to configure SPF records for our domains. I started out trying
to use the Microsoft Sender ID Framework SPF Record wizard at
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/.

However after pulling out my hair with ambiguous error messages I ended up
using the SPF setup wizard at http://www.openspf.org/.

Using the wizard I was able to generate the following SPF record:

v=spf1 ip4:216.42.131.0/25 ip4:157.238.141.0/25 ip4:198.87.208.0/24
ip4:198.87.209.0/24 ip4:207.67.38.0/25 a mx a:smtp.frontiernet.net
a:smtp-server.rochester.rr.com a:www.netpot.com a:smtp.charter.net
a:smtp.shoreham.net a:smtpauth.earthlink.net a:smtp.sbcglobal.yahoo.com
a:smtp.east.cox.net a:mail.montanadsl.net -all

This is all well and good, but when I went to create a TXT record on our
Windows 2000 DNS server the record was truncated down to:

v=spf1 ip4:216.42.131.0/25 ip4:157.238.141.0/25 ip4:198.87.208.0

I tried adding line breaks to the record as follows:

v=spf1
ip4:216.42.131.0/25
ip4:157.238.141.0/25
ip4:198.87.208.0/24
ip4:198.87.209.0/24
ip4:207.67.38.0/25
a
mx
a:smtp.frontiernet.net
a:smtp-server.rochester.rr.com
a:www.netpot.com
a:smtp.charter.net
a:smtp.shoreham.net
a:smtpauth.earthlink.net
a:smtp.sbcglobal.yahoo.com
a:smtp.east.cox.net
a:mail.montanadsl.net
-all

However we're seeing inconsistent SPF results from various MTA's. (Some
servers classify our messages as SPF_PASS and others as SPF_FAIL) Is anyone
here familiar enough with SPF to know if adding line breaks is valid syntax?

Thanks
Brad
 
I am trying to configure SPF records for our domains. I started out trying
to use the Microsoft Sender ID Framework SPF Record wizard at
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/.

However after pulling out my hair with ambiguous error messages I ended up
using the SPF setup wizard at http://www.openspf.org/.

Using the wizard I was able to generate the following SPF record:

v=spf1 ip4:216.42.131.0/25 ip4:157.238.141.0/25 ip4:198.87.208.0/24
ip4:198.87.209.0/24 ip4:207.67.38.0/25 a mx a:smtp.frontiernet.net
a:smtp-server.rochester.rr.com a:www.netpot.com a:smtp.charter.net
a:smtp.shoreham.net a:smtpauth.earthlink.net a:smtp.sbcglobal.yahoo.com
a:smtp.east.cox.net a:mail.montanadsl.net -all

This is all well and good, but when I went to create a TXT record on our
Windows 2000 DNS server the record was truncated down to:

v=spf1 ip4:216.42.131.0/25 ip4:157.238.141.0/25 ip4:198.87.208.0

I tried adding line breaks to the record as follows:

v=spf1
ip4:216.42.131.0/25
ip4:157.238.141.0/25
ip4:198.87.208.0/24
ip4:198.87.209.0/24
ip4:207.67.38.0/25
a
mx
a:smtp.frontiernet.net
a:smtp-server.rochester.rr.com
a:www.netpot.com
a:smtp.charter.net
a:smtp.shoreham.net
a:smtpauth.earthlink.net
a:smtp.sbcglobal.yahoo.com
a:smtp.east.cox.net
a:mail.montanadsl.net
-all

However we're seeing inconsistent SPF results from various MTA's. (Some
servers classify our messages as SPF_PASS and others as SPF_FAIL) Is anyone
here familiar enough with SPF to know if adding line breaks is valid syntax?

Thanks
Brad
Click to expand...
*********** REPLY SEPARATER ***********
I am no expert, but here are a few suggestions.
#1: Until you are comfortable with your SPF record, use ~all instead of -all.
This is a soft fail which still provides an SPF result, but tells the other end
that you are not quite sure about it. Receiving servers are not supposed to
reject on soft fail (yet).
#2: Keep your total DNS response record to less than 512 bytes. This is the
limit for a UDP record, as many DNS servers cannot handle TCP records.
#3: There can only be one v=spf1 txt record. Extra records will be ignored or
produce an error. I don't know how Windows DNS handles it, but I don't believe
a <CRLF> breaks SPF as long as you have the space separater.
#5: The "a" by itself is rather useless and not recommended.
#6: The same can be said for the "mx". Although it doesn't create any extra DNS
traffic, it is rather useless if it is covered elsewhere.

Finally, you seem to have included everything but the kitchen sink. An SPF
record is supposed to advertise the sending policy for a particular domain, but
your record looks more like a spammers policy than a legitimate sender. If you
send us the domain(s) in question, we can check the actual response.

J.A. Coutts
 
#1: Until you are comfortable with your SPF record, use ~all instead
of -all.

This is a soft fail which still provides an SPF result, but tells the other
end

that you are not quite sure about it. Receiving servers are not supposed to

reject on soft fail (yet).



That was semi intentional. We made a concerted effort to ensure we had every
possible host that would potentially send mail from our domain included. You
have a point though. I will probably switch back to ~ (soft fail)





#2: Keep your total DNS response record to less than 512 bytes. This is the

limit for a UDP record, as many DNS servers cannot handle TCP records.



I'd like to make it shorter but I'm not sure how I can do this and still
include everything we need. (See below for clarification)





#3: There can only be one v=spf1 txt record. Extra records will be ignored
or

produce an error. I don't know how Windows DNS handles it, but I don't
believe

a <CRLF> breaks SPF as long as you have the space separater.



We only have one record. I don't know about <CRLF> either - if its not an
issue then maybe we have a different problem.





#5: The "a" by itself is rather useless and not recommended.

#6: The same can be said for the "mx". Although it doesn't create any extra
DNS

traffic, it is rather useless if it is covered elsewhere.



Noted. I'll remove both of these.





Finally, you seem to have included everything but the kitchen sink. An SPF

record is supposed to advertise the sending policy for a particular domain,
but

your record looks more like a spammers policy than a legitimate sender. If
you

send us the domain(s) in question, we can check the actual response.



As mentioned above we are trying to ensure that we have every possible host
that could potentially send mail for our domain:



The ranges of IP's are all IPs that we control (we're an application service
provider). The reality of the matter is that we only use a small subset of
IPs for sending mail however to assure that we aren't making changes to our
SPF records every time we add a new SMTP server, I thought it would be a
good idea to include all our ip ranges to make sure we don't have problems
later on.



The various 'a' records are actually SMTP servers of our employees ISPs.
(Our employees all work from home offices) Due to mail routing issues (which
are a bit complicated to explain) our employees can't always use our primary
server to send mail.



So I guess I am back to my original question. Do line returns break SPF? If
so how do we avoid them and still include all the hosts that may send mail
for our domain. Alternatively is there some other way we can include
everything and still shorten the record.



Thanks in advance for your assistance and recommendations.

Brad





*********** REPLY SEPARATER ***********

I am no expert, but here are a few suggestions.

#1: Until you are comfortable with your SPF record, use ~all instead
of -all.

This is a soft fail which still provides an SPF result, but tells the other
end

that you are not quite sure about it. Receiving servers are not supposed to

reject on soft fail (yet).

#2: Keep your total DNS response record to less than 512 bytes. This is the

limit for a UDP record, as many DNS servers cannot handle TCP records.

#3: There can only be one v=spf1 txt record. Extra records will be ignored
or

produce an error. I don't know how Windows DNS handles it, but I don't
believe

a <CRLF> breaks SPF as long as you have the space separater.

#5: The "a" by itself is rather useless and not recommended.

#6: The same can be said for the "mx". Although it doesn't create any extra
DNS

traffic, it is rather useless if it is covered elsewhere.



Finally, you seem to have included everything but the kitchen sink. An SPF

record is supposed to advertise the sending policy for a particular domain,
but

your record looks more like a spammers policy than a legitimate sender. If
you

send us the domain(s) in question, we can check the actual response.



J.A. Coutts








I am trying to configure SPF records for our domains. I started out trying

to use the Microsoft Sender ID Framework SPF Record wizard at

http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/.



However after pulling out my hair with ambiguous error messages I ended up

using the SPF setup wizard at http://www.openspf.org/.



Using the wizard I was able to generate the following SPF record:



v=spf1 ip4:216.42.131.0/25 ip4:157.238.141.0/25 ip4:198.87.208.0/24

ip4:198.87.209.0/24 ip4:207.67.38.0/25 a mx a:smtp.frontiernet.net

a:smtp-server.rochester.rr.com a:www.netpot.com a:smtp.charter.net

a:smtp.shoreham.net a:smtpauth.earthlink.net a:smtp.sbcglobal.yahoo.com

a:smtp.east.cox.net a:mail.montanadsl.net -all



This is all well and good, but when I went to create a TXT record on our

Windows 2000 DNS server the record was truncated down to:



v=spf1 ip4:216.42.131.0/25 ip4:157.238.141.0/25 ip4:198.87.208.0



I tried adding line breaks to the record as follows:



v=spf1

ip4:216.42.131.0/25

ip4:157.238.141.0/25

ip4:198.87.208.0/24

ip4:198.87.209.0/24

ip4:207.67.38.0/25

a

mx

a:smtp.frontiernet.net

a:smtp-server.rochester.rr.com

a:www.netpot.com

a:smtp.charter.net

a:smtp.shoreham.net

a:smtpauth.earthlink.net

a:smtp.sbcglobal.yahoo.com

a:smtp.east.cox.net

a:mail.montanadsl.net

-all



However we're seeing inconsistent SPF results from various MTA's. (Some

servers classify our messages as SPF_PASS and others as SPF_FAIL) Is anyone

here familiar enough with SPF to know if adding line breaks is valid syntax?



Thanks

Brad
 
In
Brad Baker said:
The two domains in question are

uniteu.com:
http://www.dnsstuff.com/tools/lookup.ch?name=uniteu.com&type=TXT
uniteu.net:
http://www.dnsstuff.com/tools/lookup.ch?name=uniteu.net&type=TXT
Thanks Again,
Brad
Click to expand...

Brad, your record returns as such:
_______________________
uniteu.com text =

"v=spf1"
"ip4:216.42.131.0/25"
"ip4:157.238.141.0/25"
"ip4:198.87.208.0/24"
"ip4:198.87.209.0/24"
"ip4:207.67.38.0/25"
"a"
"mx"
"a:smtp.frontiernet.net"
"a:smtp-server.rochester.rr.com"
"a:www.netpot.com"
"a:smtp.charter.net"
"a:smtp.shoreham.net"
"a:smtpauth.earthlink.net"
"a:smtp.sbcglobal.yahoo.com"
"a:smtp.east.cox.net"
"a:mail.montanadsl.net"
"-all"
uniteu.net
Click to expand...
Server: rbru.br.rs.els-gms.att.net
_______________________



The SPF should be one record, on one line, such as:


_______________________
nslookup
set q=txt
rsesdelval.com

Non-authoritative answer:
rsesdelval.com text =

"v=spf1 ip4:207.106.134.250/24 mx a:ponyexpress.bandwidthpros.com
a:mail
..bandwidthpros.com mx:ponyexpress.bandwidthpros.com
mx:mail.bandwidthpros.com pt
r:mail.bandwidthpros.com -all"
_______________________


I may have extra data in this record, but the point is it's all one record.
I'm not entirely sure how you are creating it, but in the box, I would
create it in notepad or the SPF site, then just rt-click on your zone,
select other record, select txt record, then copy and paste the whole thing
as one record in one shot and let it line wrap. Did you try it that way?

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Having difficulty reading or finding responses to your post?
Instead of the website you're using, I suggest to use OEx (Outlook Express
or any other newsreader), and configure a news account, pointing to
news.microsoft.com. This is a direct link to the Microsoft Public
Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows you
to easily find, track threads, cross-post, sort by date, poster's name,
watched threads or subject.

Not sure how? It's easy:
How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Windows Server Directory Services
Microsoft Certified Trainer
Assimilation Imminent. Resistance is Futile.
Infinite Diversities in Infinite Combinations.

The only thing in life is change. Anything less is a blackhole consuming
unnecessary energy.
===========================
 
Brad said:
I am trying to configure SPF records for our domains. I started out
trying to use the Microsoft Sender ID Framework SPF Record wizard at
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/.

However after pulling out my hair with ambiguous error messages I
ended up using the SPF setup wizard at http://www.openspf.org/.

Using the wizard I was able to generate the following SPF record:

v=spf1 ip4:216.42.131.0/25 ip4:157.238.141.0/25 ip4:198.87.208.0/24
ip4:198.87.209.0/24 ip4:207.67.38.0/25 a mx a:smtp.frontiernet.net
a:smtp-server.rochester.rr.com a:www.netpot.com a:smtp.charter.net
a:smtp.shoreham.net a:smtpauth.earthlink.net
a:smtp.sbcglobal.yahoo.com a:smtp.east.cox.net a:mail.montanadsl.net
-all

This is all well and good, but when I went to create a TXT record on
our Windows 2000 DNS server the record was truncated down to:

v=spf1 ip4:216.42.131.0/25 ip4:157.238.141.0/25 ip4:198.87.208.0

I tried adding line breaks to the record as follows:

v=spf1
ip4:216.42.131.0/25
ip4:157.238.141.0/25
ip4:198.87.208.0/24
ip4:198.87.209.0/24
ip4:207.67.38.0/25
a
mx
a:smtp.frontiernet.net
a:smtp-server.rochester.rr.com
a:www.netpot.com
a:smtp.charter.net
a:smtp.shoreham.net
a:smtpauth.earthlink.net
a:smtp.sbcglobal.yahoo.com
a:smtp.east.cox.net
a:mail.montanadsl.net
-all

However we're seeing inconsistent SPF results from various MTA's.
(Some servers classify our messages as SPF_PASS and others as
SPF_FAIL) Is anyone here familiar enough with SPF to know if adding
line breaks is valid syntax?
Click to expand...

You can't use line breaks in a TXT record for SPF. Copy and paste it to the
TXT record, all on one line. That should put a scroll bar at the bottom of
the TXT record. If it doesn't that is another problem. But the SPF data must
be on one line with no tabs.
 
The two domains in question are

uniteu.com: http://www.dnsstuff.com/tools/lookup.ch?name=uniteu.com&type=TXT
uniteu.net: http://www.dnsstuff.com/tools/lookup.ch?name=uniteu.net&type=TXT

Thanks Again,
Brad
Click to expand...
*********** REPLY SEPARATER ************
Your SPF record comes back as:
Server: dns1.uniteu.net
Address: 216.42.131.103
uniteu.net text =
"v=spf1"
"ip4:216.42.131.0/25"
"ip4:157.238.141.0/25"
"ip4:198.87.208.0/24"
"ip4:198.87.209.0/24"
"ip4:207.67.38.0/25"
"a"
"mx"
"a:smtp.frontiernet.net"
"a:smtp-server.rochester.rr.com"
"a:www.netpot.com"
"a:smtp.charter.net"
"a:smtp.shoreham.net"
"a:smtpauth.earthlink.net"
"a:smtp.sbcglobal.yahoo.com"
"a:smtp.east.cox.net"
"a:mail.montanadsl.net"
"-all"
There are a number of places on the Internet that you can test SPF results.
When I check your domain on one of these, it comes back with "Domain of
uniteu.net has no SPF Record". You should try to get it all in one line with a
space separater, and I believe Kevin offered some suggestions on how to do that
with Windows DNS.

J.A. Coutts
 
In
John Coutts said:
There are a number of places on the Internet that you can test SPF
results. When I check your domain on one of these, it comes back with
"Domain of uniteu.net has no SPF Record". You should try to get it
all in one line with a space separater, and I believe Kevin offered
some suggestions on how to do that with Windows DNS.

J.A. Coutts
Click to expand...

Same exact thing I saidJohn.

:-)

Ace
 
That's just the problem! :-)



When we tried to enter the contents of the record generated by the official
SPF website, Windows DNS truncated it rather than adding line feeds. So we
ended up with 1/2 of what we originally entered. I tried adding in carriage
returns manually, but that doesn't seem to work either.



The SPF record testers I tried gave me inconsistent results. (For instance
when I test using Microsoft's SPF tester it's perfectly content with just
about anything I enter, whereas some of the other ones I have tried do not
seem to like our records.)



Per the article/link I included above I think what I need to do is break
this up into multiple records and then use the SPF "include" statement. I
haven't tried this yet though.



Brad





"Ace Fekay [MVP]"
 
Brad said:
That's just the problem! :-)



When we tried to enter the contents of the record generated by the
official SPF website, Windows DNS truncated it rather than adding
line feeds. So we ended up with 1/2 of what we originally entered. I
tried adding in carriage returns manually, but that doesn't seem to
work either.
Click to expand...

Then I would suspect the DNS console is corrupted, because that is not what
is supposed to happen. I've created SPF on both Win2k and Win2k3 with no
problem. It just adds a scroll bar at the bottom of the TXT dialog.


Try installing the adminpak.msi for what ever version of Windows you are
using to see if it will reinstall the console.
 
That's just the problem! :-)
When we tried to enter the contents of the record generated by the official
SPF website, Windows DNS truncated it rather than adding line feeds. So we
ended up with 1/2 of what we originally entered. I tried adding in carriage
returns manually, but that doesn't seem to work either.

The SPF record testers I tried gave me inconsistent results. (For instance
when I test using Microsoft's SPF tester it's perfectly content with just
about anything I enter, whereas some of the other ones I have tried do not
seem to like our records.)

Per the article/link I included above I think what I need to do is break
this up into multiple records and then use the SPF "include" statement. I
haven't tried this yet though.

Brad
Click to expand...
************* REPLY SEPARATER **************
The use of the "Include" is certainly an option as long as the providers supply
and maintain their own SPF record. "Include" simply tells the receiver to use
the SPF record supplied by an alternate domain. But I disagree with your
concept of using all the available IPs. What that tells me as a potential
receiver is that you really don't care where mail is sent from.

J.A. Coutts
 
In
Brad Baker said:
That's just the problem! :-)

When we tried to enter the contents of the record generated by the
official SPF website, Windows DNS truncated it rather than adding
line feeds. So we ended up with 1/2 of what we originally entered. I
tried adding in carriage returns manually, but that doesn't seem to
work either.
The SPF record testers I tried gave me inconsistent results. (For
instance when I test using Microsoft's SPF tester it's perfectly
content with just about anything I enter, whereas some of the other
ones I have tried do not seem to like our records.)

Per the article/link I included above I think what I need to do is
break this up into multiple records and then use the SPF "include"
statement. I haven't tried this yet though.

Brad
Click to expand...

I am tending to agree with Kevin that the console is corrupt. Try his
suggestion. Unless of course you are worried when you do copy and paste that
you don't "see" the whole record in the text field when you created it.

I see you made some headway, but with the include statement:
set q=txt
uniteu.com
Click to expand...
Server: london.nwtraders.msft
Address: 192.168.5.200

uniteu.com text =

"v=spf1 include:spfips.uniteu.com include:spfmx1.uniteu.com
include:spfm
x2.uniteu.com include:exacttarget.com include:bounce.exacttarget.com -all"
uniteu.net
Click to expand...
Server: rbru.br.rs.els-gms.att.net
Address: 199.191.128.103

uniteu.net text =

"v=spf1 include:spfips.uniteu.com include:spfmx1.uniteu.com
include:spfm
x2.uniteu.com include:exacttarget.com include:bounce.exacttarget.com -all"
Ace
 
In response to "What that tells me as a potential receiver is that you
really don't care where mail is sent from.":

There are too many legitimiate potential sources of email for our domain. We
have employee's sending mail from home offices using their ISP's SMTP
servers, plus we have a plethora of web servers which each have their own
SMTP servers. Could I narrow it down further - certainly.

However if we add another web server (and corresponding SMTP server) the ip
address for that server could come from any one of the four pools of ip
addresses I defined in our SPF record. I don't know which pool the ip
address will come from until I build the server.

If I narrow down the list of IP's then forget to update our SPF record when
we build a new server, then mail from the new server could be blacklisted.
Does that make sense?

Therefore, yes I have cast a pretty wide pool of sources from which mail for
our domain could originate. I'm struggling to figure out how we might be
able to narrow this down a bit and make our SPF record more mangable.

Brad
 
In
Brad Baker said:
In response to "What that tells me as a potential receiver is that you
really don't care where mail is sent from.":

There are too many legitimiate potential sources of email for our
domain. We have employee's sending mail from home offices using their
ISP's SMTP servers, plus we have a plethora of web servers which each
have their own SMTP servers. Could I narrow it down further -
certainly.
However if we add another web server (and corresponding SMTP server)
the ip address for that server could come from any one of the four
pools of ip addresses I defined in our SPF record. I don't know which
pool the ip address will come from until I build the server.

If I narrow down the list of IP's then forget to update our SPF
record when we build a new server, then mail from the new server
could be blacklisted. Does that make sense?

Therefore, yes I have cast a pretty wide pool of sources from which
mail for our domain could originate. I'm struggling to figure out how
we might be able to narrow this down a bit and make our SPF record
more mangable.
Brad
Click to expand...

That's an interesting and difficult scenario. I have a client in a similar
situation with over 150 domains. They don't have clients sending from their
ISP's server, but rather from the SMTP service on the webserver for that
specific domain. In some cases, there are over 15 domains on a webserver,
and the originating From address is someother domain that doesn't match the
SPF record for that domain.

Here's the scenario. Say if the my client's has a customer with a domain
name of example.com. The example.com email server is being hosted at the
customer's site and we have no control over it. The customer's website has
an "info" or a "contact" page that will allow someone to fill out a form,
use their email address as the 'from' address, such as
'(e-mail address removed), then the website using CDONT sends it to the
customer's email address, such as (e-mail address removed), their email server would
reject this legitimate email because they are dilligently checking SPF
records and the website's IP address, or even it's reverse entry, doesn't
match Hotmail's SPF. In this case we had to tell the customer to allow the
webserver, but they refused to do so citing it can be compromised and it can
well possibly be spam. Even if my client were to allow relay from their
server to the customer's email server, it would still block it. Eventually
they had to allow the website's IP.

Now in your case, I probably would, that is if we owned all the SMTP
servers, to allow them to relay through our server and just set each
domain's SPF record with the IP of this server. But the only issue with this
case, is the reverse doesn't match the MX entry, which many are starting to
keep track of. Same with the SMTP banner during a telnet sessions HELO.

Another solution would be to use only one mail server for ALL of these
domains. Set the MX record on each domain to be sent to the main domain's MX
record, such as:

maindomain.com
www A b.b.b.b
mail A c.c.c.c
@ MX mail.maindomain.com
"v=spf1 ip4:c.c.c.c/29 a:mail.maindomain.com ~all"

domain1.com
www A x.x.x.x
mail A c.c.c.c
@ MX mail.domain1.com
"v=spf1 ip4:c.c.c.c/29 a:mail.domain1.com ~all"

domain2.com
www A y.y.y.y
@ MX mail.maindomain.com
mail A c.c.c.c
"v=spf1 ip4:c.c.c.c/29 a:mail.domain2.com ~all"


You have an interesting situation and it will be extremely difficult for any
receiving SMTP MTA to allow if they are doing strict checking.

The only thing bad with this is the PTR can only be set once, and of course
in most cases be set to mail.maindomain.com for the c.c.c.c IP address. If
someone is doing a strict check, it will be considered spam.

Ace
 
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
Carl R said:
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"
Click to expand...

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

Thanks,
Ace
 
Back
Top