Mark Minasi's Windows Networking Tech Page
Issue #52 November 2005

To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. To change e-mail address, switch between HTML or text format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.  Visit the Archives at http://www.minasi.com/archive.htm.  Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp.  Document copyright 2005 Mark Minasi.

What's Inside

  • News
    • LAST CHANCE... Active Directory and Security Classes in DC Next Monday, Wednesday
  • Tech Section
    • A More Modern Take on NET TIME... W32TM
    • Questions and Answers On SPF
  • Conferences
  • Bring a Seminar to Your Site

News

This month, I've got an update on the Windows Time Service and the responses to questions that many of you had about SPF.  This issue's a bit short and sweet, but I think you'll find a tip or two in here, including a very simplified suggestion on building your own SPF records.  But first, a word from our sponsor...

LAST CHANCE... Active Directory and Security Classes in DC Next Monday, Wednesday

I'm trying to stay off the road so I can start working on Server R2 and Vista books, but a fair number of folks have kindly asked for another seminar... so here goes.  The only public seminars I will do for the rest of the year (and probably a good bit of the next) will be in Washington, DC at the Marriott near George Washington University next Monday through Thursday.  I'll be running the Active Directory class and the Security class.  You can find the Security class (which is now twice the size and three times as many PowerPoint slides, all packed into two enlightening days) outline is at www.minasi.com/secoutln.htm, the Active Directory class outline is at www.minasi.com/2003outln.htm, and you can find the seminar registration page at www.minasi.com/pubsems.htm.

Tech Section

Amplifying our last newsletter on Windows Time Service, and more on SPF...

A More Modern Take On NET TIME... W32TM

Last newsletter I mentioned that Server 2003 behaved differently from 2000 and XP when it came to NET TIME, noting that you need to restart the W32TIME service after doing a NET TIME /SETSNTP command.  Reader Matt Lichstein e-mailed me to spank me for not knowing that NET TIME has been "deprecated," computer-talk for "this command's still around now, but don't expect it in the future!"  (ANd Matt's got a Microsoft e-mail address, so I'm guessing he knows what he's talking about.)  The w32tm command, which I covered in the 2003 book as the command-line tool to force a reset of the Windows Time Service, can also replace NET TIME, Matt tells me.  So I looked into it and, sure enough, he's right.

The particular w32tm option that we're looking for is the "/configure" parameter.  It sets two things.  First, it tells W32Time whether or not to look for a time server within an Active Directory hierarchy.  You may recall that if your system is a member of an Active Directory, then you don't tell it where to get its time from; instead, it gets it from some other AD member in a hierarchy with just one machine at the top -- the PDC emulator FSMO for the root domain.  (This is written up in the book so I'll spare you the long explanation, but in short it's the first DC that you ever install in the first domain in your forest.  At least until you decommission that DC; after that, it's whatever DC you transferred the PDC FSMO role over to when you decommissioned that first DC.)  For non-AD members or

This is controlled normally by a Registry entry in HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters called "Type," and it's either set to "NT5DS" if you're in an AD, or "NTP" if you're either not an AD member, or if you're the root domain's PDC emulator FSMO -- that first-DC-in-the-forest that I just referred to.  I explained all of this back in Newsletter #16, but monkeying around with the Registry's never fun, so w32tm makes it a bit easier.

To tell a system's W32Time service to get its time from the Active Directory, type

w32tm /configure /syncfromflags:domhier /update

This does two things.  First, it sets that Type value to "NT5DS."  Second, it restarts the W32Time service, or at least notifies it that things have changed.

But what about a system that's not a member of an AD?  In that case, change two things.  First, the /syncfromflags option's value changes from "domheir" to "manual."  That will change the Type value from "NT5DS" to "NTP."  Second, you'll need to tell it the name of the server to get time from.  You do that by adding the /manualpeerlist: option, which behaves the same way as the /setsntp: option works in NET TIME -- it lets you specify one time server, or a number of potential time servers in a list surrounded by quotes.  To tell your system that it's on its own for time and to start synchronizing from time.windows.com, you'd type

w32tm /configure /manualpeerlist:time.windows.com /syncfromflags:manual /update

Then, as before, tell your system to update its time with this command:

w32tm /resync

And if you're in search of a time server, just use any Internet search engine and search on "public time servers" or "public NTP servers."  As Matt notes, if you do a w32tm /? then you'll see a bunch of options.  My thanks to Matt!

More On SPF

A lot of you wrote to tell me that you liked the articles on defeating spam and about implementing SPF records on your DNS domain in Newsletter #51, which you can read here.  Some had some questions and needed a bit of clarification.  Here are the questions and answers.

Won't this cause me to block e-mail from legitimate senders who haven't implemented SPF records?

If I install an SPF filter on my SMTP server then that surely sounds nice, but the fact is that most domains don't yet have SPF records in their DNS domains.  Won't I end up bouncing a lot of good mail?

Answer:  no.  Remember, an SPF filter looks at a given domain's DNS zone, seeking an SPF record.  Based on that, the SPF filter scores the incoming mail as "pass," "fail," or (to simplify things) "I don't know."  It depends on what SPF filter software you're running, but in general it's simple (and typical) under SPF to say, "only reject incoming e-mails who have explicitly failed based on an SPF record."  In other words, if your SMTP server sees an incoming e-mail claiming to be from, say, whitehouse.gov, then your server will contact the whitehouse.gov DNS server and ask if it's got a TXT record with SPF information in it.  Those dodos at the White House IT staff haven't bothered to create an SPF record, so your SPF filter wouldn't find an SPF record, and would score the incoming e-mail as "I don't know" rather than "fail."  Assuming that you've told your SPF filter to only reject explicit "fail" messages, then the e-mail would be delivered.  So if you're waiting for W to say "howdy," then you needn't worry.

SPF will only work if everyone publishes SPF records.

Not at all.  Heck, if the only person in the world who published an SPF record were me and if the only person in the world who ran an SPF checker were me, then I'd still see a benefit:  no more spam addressed to me... from me!  For that matter, if Paypal publishes SPF records (as they do) then anyone running an SPF filter should never again have to see the "notice of account termination" phishing stuff.  I'd be nice if everyone took a moment and did an SPF record, but until then, it's still useful.  And every single domain that publishes a record makes SPF more and more valuable.

This is only effective for big companies who control their own DNS zones, and no good for us little guys.

Well, first, if you run your own SMTP server, then there's probably nothing keeping you from running your own DNS server.  Yes, you're supposed to run two DNS servers but you can either get an ISP to act as a secondary for a small fee, or just tell 'em that you've got two servers and, um, never get around to setting up the second one.<g>

Second, in my experience every ISP I've worked with who hosts a DNS zone will let you put just about anything that you want in it.  Some have Web pages that let you edit your DNS zone.  For others, you'll need to call their tech support people.  But if you've got a static IP address and someone else is hosting your DNS for you, then I cannot imagine why they wouldn't let you tell them to insert a TXT record.

Third, if we're talking a dynamic IP address, then most people who want to host their own servers end up going with some kind of dynamic DNS hosting service, in which case you run your own DNS server.

Either way, creating a simple TXT record with SPF information in it should not be a barrier to publishing SPF records.

SPF is ineffective as spammers will just register their domains and include SPF records.

It's certainly true that spammers could do that.  But remember, I said in the article that SPF's main virtue is in making it difficult to forge return addresses.  The anti-spam aspect of this comes in two parts.  First, it's no longer possible for you to get an e-mail, as I've said, from yourself, unless you really did send yourself an e-mail.  Second, it's harder for phishing schemes to go on, as I've already mentioned.

What happens if a spammer registers a domain and spams from it?  We soon learn of it, and blacklist that domain.  Sure, a spammer can just hop around, creating domains before a spam blast, but it's more work.  And as time goes on we'll have better authenticated and reputation-based systems.

I could just spoof an IP address of an SMTP server for a legitimate domain.

One reader said

...if I wanted to get around SPF, and I wanted to use a from domain which was verifiable via SPF, I would write a small piece of software which queried DNS for the permitted email sending IP for my chosen domain (bigcompany.com), then sent the spam email to the target recipient's incoming email server, with the IP headers constructed to appear as though my PC was just a router on the internet forwarding a packet originating from the IP of bigcompany.com. Spoofing source IP like this is trivially easy, and is the obvious way around SPF. You can be sure there will be software available for download by spammers to do this before SPF has even achieved significant partial coverage of the internet.

This is not bad reasoning, save for one small flaw -- the notion of IP spoofing.  Let's look at how IP spoofing works, and why it won't work here.

When my system sends an IP packet to another system, that IP packet contains a number of pieces of information.  Two of the most important of those pieces of information are the source and destination IPs -- who I am, and who I'm trying to talk to.  The source IP address is important, as it becomes the return address, the IP that the destination uses to reply to the source.

When you spoof an IP address, you craft an IP packet that lies about the source IP address.  This is useful for bad guys who want to do things like send bezillions of IP packets at a router with the intention of overloading that router and creating a denial of service attack.  They spoof a return IP address for several reasons, but the most obvious one is that they don't want to get caught.

In light of this then yes, it seems that anyone could build systems that can do criminal things and, though the magic of spoofing, remain undetected.  But that's not so.  Recall that in the Internet, there are two main kinds of protocols that live atop IP -- UDP and TCP.  UDP communications are like a message in a bottle; they're dropped on the Internet and you have no idea where they actually went or who actually got it, if anyone.  TCP, in contrast, is connection-oriented and doesn't work until you've established a conversation.  The would-be client says to the would-be server, "let's talk," and the would-be server must reply, "sure" before anything can happen.  But if the would-be client proffers an invalid source IP address -- a bogus "return address," then the server's "sure" never gets back to the client, and the connection is never established.  But -- and here's the important part -- SMTP can't work without TCP.  So while spoofing source IPs are trivially easy on non-Windows systems (there's protection against such spoofing built into XP SP2 and 2003 SP1), spoofing IPs and thereby creating an SMTP conversation isn't so easy.

I'm still confused.  Is there a really easy way to build an SPF record?

You betcha.  Use the "a" mechanism to name specific systems that are allowed to send e-mail for you.  Or the "ip4" mechanism.

For example, let's suppose that bigfirm.com has only two servers that it authorizes to send e-mail for them, mail.bigfirm.com and mailserver.someisp.com.  Anyone else claiming to be sending e-mail for bigfirm.com should be rejected.  Put this SPF record into the bigfirm.com DNS zone:

v=spf1 a:mail.bigfirm.com a:mailserver.someisp.com -all

This will always pass the MAIL FROM test.  To pass the EHLO/HELO test, just make sure that the PTR records for mail.bigfirm.com and mailserver.someisp.com return IP addresses that match the actual IP addresses of those two systems.

Alternatively, you can go with the easiest and most specific mechanism, ip4.  Just specify the IP addresses of the only systems that you want to send e-mail for your domain, and name those IP addresses.  In the above example,suppose that mail.bigfirm.com has an IP address of 101.88.77.2 and mailserver.someisp.com has an IP address of 100.100.1.3.  Put this SPF record into bigfirm.com's DNS zone instead of the previous one:

v=spf1 ip4:101.88.77.2  ip4:100.100.1.3 -all

That will pass both the MAIL FROM and EHLO/HELO tests without trouble.

You dope, SPF records are read left to right, not right to left!

Ummm, yeah, that's right, I goofed.  You see, I've been trying to learn Hebrew in my spare time, and I got confused...<g>  Thanks to those who caught this so I could fix it before many of you read this.

Can I do SPF with Microsoft's SMTP server?

The SMTP server built into IIS can't do SPF checking right out of the box, but if you visit http://www.gfi.com/mes/mesfreeware.htm then you'll find a free tool that lets you add DNS blacklisting, SPF checking, automatic disclaimers at the end of every outgoing message, and custom blacklisting.  I have not played with it, but I'm told it works very well.

Thanks again to everyone who commented, I'm very glad that I could make SPF a bit easier to understand. As always, please feel free to let me know what you think!

Conferences

Join me at ...

TechTarget's Web Class on SP2 and SP1.  As they say it...

"Windows School is in session with Mark Minasi Mark Minasi dissects Windows XP SP2 and Windows Server 2003 SP1 in five, 15-minute webcast cram sessions. You can even download a worksheet to follow along with the lesson you're hearing. Find out the good and bad about XP SP2 and Windows 2003 SP1 in Mark's inimitable style. Topics cover: Data execution protection, stack changes, de-anonymizing XP, IE and more."
http://searchwin2000.techtarget.com/general/0,295582,sid1_gci1084934,00.html?offer=minasi

Bring Mark to your site to teach

I'm keeping busy doing Active Directory and Security seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000, XP, Active Directory and 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, and other organizations that I've assisted, either take a peek at the course outlines at www.minasi.com/presentations.htm, mail our assistant Jean Snead at Assistant@Minasi.com, or call her at (757) 426-1431 (only between noon-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I'd like very much to expand this periodical into a useful source of NT/2000/2003/XP information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 40,000 subscribers and I hope to use this to get information to every single Mastering 2003, XP, NT and 2000 Server reader. Thanks for letting me visit with you, and take care.  Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at http://www.minasi.com/gethelp and please join us at the Forum with technical questions at www.minasi.com/forum. 

To subscribe, visit http://www.minasi.com/nwsreg.htm. To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.  To unsubscribe, link to http://www.minasi.com/unsubs.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.

All contents copyright 2005 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.