Re: SPF Configurations
On Tue, 8 Dec 2009, Suresh Ramasubramanian wrote: As for a university smarthost getting blocked you'd probably need to look at one of two things - Three :-) 1. Forwarding users on your campus - with mailboxes that accept a lot of spam and then forward it over to student / alumni AOL, Comcast, Yahoo etc accounts 2. Spam generated by infected PCs / laptops, hacked machines etc on your campus LAN 3. Spammers abusing your webmail and/or remote message submission service using phished credentials. If your incoming spam blocks are effective then forwarding shouldn't be too much of a problem. For on-campus bots, block port 25 and ensure your MX servers can't be used as outgoing relays (i.e. put your outgoing relay service on a separate address). If you are lucky your colleagues chose a really obscure name (not mail.* or smtp.* etc.) for your outgoing relay service 20 years ago so spammers are less likely to guess it :-) To protect against phished accounts, apply rate-limits to outgoing email. If you have good on-campus security hygeine then you can be much less strict about the limits for on-campus connections. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: SPF Configurations
Absolutely #3 - far more of a threat than #1 and #2. On Tue, Dec 8, 2009 at 10:09 PM, Tony Finch d...@dotat.at wrote: Three :-) 1. Forwarding users on your campus - with mailboxes that accept a lot of spam and then forward it over to student / alumni AOL, Comcast, Yahoo etc accounts 2. Spam generated by infected PCs / laptops, hacked machines etc on your campus LAN 3. Spammers abusing your webmail and/or remote message submission service using phished credentials. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: SPF Configurations
3. Spammers abusing your webmail and/or remote message submission service using phished credentials. I'll admit .. this has happened a few times too. Usually we see the incoming phish attempt and configure an outbound block for RE: (same subject) and it never fails .. we catch at least one person that responds. We've seriously considered sending our own phishing emails with a link that automatically disables anyone's account if they click it. If your incoming spam blocks are effective then forwarding shouldn't be too much of a problem. Never-ending game of cat mouse. Our volume is 1.5-2m msg/day, and I'd say we catch ~95% of it .. but when a batch gets through and a third of our students have mail forwarded to Yahoo, from Yahoo's point-of-view, they just got 10,000 spam from our IPs. For on-campus bots, block port 25 and ensure your MX servers can't be used as outgoing relays We do that, as well as run daily reports on outbound ACL denies to see who's been compromised (or being naughty on purpose). (i.e. put your outgoing relay service on a separate address). If you are lucky your colleagues chose a really obscure name (not mail.* or smtp.* etc.) They did. To protect against phished accounts, apply rate-limits to outgoing email. If you have good on-campus security hygeine then you can be much less strict about the limits for on-campus connections. Anyone know how to do this in Domino off-hand? (without sending IBM a fat check) .. if so, I'd love to hear about it so I can tell our Lotus admins. Cheers, Michael Holstein Cleveland State University
Re: SPF Configurations
On Sun, 6 Dec 2009, Bill Stewart wrote: On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan s...@donelan.com wrote: In particular, what anti-forgery/security controls should network operators implement and check; and what anti-forgery/security controls should network operators not implement or check? Depends a bit on whether you're counting inbound-mail-service operators as network operators. Because this is NANOG, I was scoping it to be just layer 0 to 4. Leaving the application and above layer discussions to other places. I would love to know how the marketplace wants to handle Official Mail, but I'm not expecting useful answers here. As an end user who doesn't have an account at Bank of America, I'd be happy if bankofamerica.com used SPF records so my mail system could discard forged spam from them; that's much different than the kind of forgery prevention I want for my actual bank. (And obviously SPF isn't going to stop mail from bank0vamer1ca.cm etc., but it can cut down some of the noise and leave the rest for Spamassassin.) Like most things, scaling is the only problem. Your Bank is different from My Bank, and His Bank and Her Bank, and so on. Throw in multiple middle-parties, i.e. the NSP, ISP, MSP, ESP, etc; and the problem becomes very difficult. And that's before adding the problem the real Your Bank (or their marketing partners, or their compromised PCs) may also send stuff you don't want. Network operations probably aren't going to solve those problems. And lots of other places like to discuss them. So instead, what things should network operators be expected to solve? If you can't trust routing, can you trust DNS? If you can't trust DNS, can you trust things using DNS? If you can't trust ???, can you trust ???
Re: SPF Configurations
On Dec 7, 2009, at 9:51 AM, Michael Holstein wrote: The problem we face is that some people we work with can't do that Then explain that client-side (their users, to whom they send mail) are probably using Hotmail, et.al. and SPF will simply not allow spoofing which is what they want to do, unless they either : A) add the SPF record as previously mentioned. It's a TXT record under their root and isn't hard at all. An authorization tied to a PRA or Mail From will not prevent spoofing, it just constrains the risks to those with access to a provider's service. A provider could insure a user controls the From email-address, but this would conflict with the IP path registration schemes. B) permit you to use a subdomain (like u...@theircompanymail.yourdomain.com). A provider can ensure any signed From email-address is controlled by its users by using ping-back email confirmations appended to user profiles. There is a proposal aimed at reducing DNS overhead and scalability issues associated with the all-inclusive IP address path registration scheme with its inability to cope with forwarded email: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03 Use of this DKIM extension can safely accommodate a user's desire to authorize third-party signatures to protect acceptance of From headers within domains that differ from the DKIM signature. DKIM does not need to change. Once IPv6 and international TLDs come into the mix, having users vote (authorize) DKIM providers could better determine what new domains can be trusted, and help ensure users are allowed to utilize their own language and to seek assistance in obtaining acceptable IPv6 connectivity. -Doug
Re: SPF Configurations
On Mon, Dec 7, 2009 at 11:21 PM, Michael Holstein michael.holst...@csuohio.edu wrote: Personally, I think SPF is a major PITA operations-wise .. but if you've ever had to fill out the form to get un-blacklisted at Yahoo/AOL, that's one of the first things they ask .. do you have a spfv1 record defined?. With yahoo and aol - they'd be just as satisfied if you used, say, DKIM. Hotmail's the only one that insists on sender-id (not spfv1 either) As for a university smarthost getting blocked you'd probably need to look at one of two things - 1. Forwarding users on your campus - with mailboxes that accept a lot of spam and then forward it over to student / alumni AOL, Comcast, Yahoo etc accounts 2. Spam generated by infected PCs / laptops, hacked machines etc on your campus LAN If you took steps to fix some of these - 1. Isolate your forwarding through a separate IP or subnet, filter it before forwarding on 2. Separate your outbound to another set of IPs, again filter and a few other things - related to this .. you'd get blocked far less. Joe St.Sauver of UOregon, being a maawg senior tech advisor and also active in EDUCAUSE etc, might have a white paper on this, like he does on most other security related issues under the sun :) -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Official Mail, was SPF Configurations
I would love to know how the marketplace wants to handle Official Mail, but I'm not expecting useful answers here. The marketplace doesn't have a clue. We have a plenty of tools in the toolbox, from heavyweight S/MIME to lighter weight DKIM+VBR to proprietary Goodmail, but among the mailers with a stake in having a reliable spoof-resistant channel I don't see much interest in doing anything other than whatever they're doing now. If it were up to me, I'd use per-recipient password-protected RSS or Atom feeds with emailed notices that just say to check your feed, but that has patent issues. R's, John
Re: SPF Configurations
On Fri, 4 Dec 2009, John Levine wrote: than the other way around, believing that it prevent forgery, having redefined forgery as whatever it is that SPF prevents. As the operator of one of the world's more heavily forged domains (abuse.net) I can report that if you think it prevents forgery blowback, you are mistaken. Nothing can prevent forgery. The forgers are going to keep making them. You can only try to make forgery easier to detect. But you need other parties' cooperation to detect the forgery and react in some way. Even if you did stop one forger, i.e. prison; there will be plenty of up and coming forgers to keep making forgeries. SPF, DKIM, PGP, S/MIME, DNSSEC, BCP38, sBGP, DRM, special paper and printing, wax seals, handwriting analysis, and so on; help cooperating parties detect particular types of forgery. Assuming the cooperating parties actually want to. Adding even more complexity probably isn't going to improve the degree of cooperation of uncooperative parties. In practice, any security control will also affect something some legitimate party wants to do sometime. And likewise, any security control can be mis-implemented or mis-used. In particular, what anti-forgery/security controls should network operators implement and check; and what anti-forgery/security controls should network operators not implement or check? Are they better implemented and checked by the application/user instead? Just as many people seem to get mad at ISPs when they do something, as get mad at ISPs when they don't do something. And its often the same something.
Re: SPF Configurations
On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan s...@donelan.com wrote: In particular, what anti-forgery/security controls should network operators implement and check; and what anti-forgery/security controls should network operators not implement or check? Depends a bit on whether you're counting inbound-mail-service operators as network operators. As an end user who doesn't have an account at Bank of America, I'd be happy if bankofamerica.com used SPF records so my mail system could discard forged spam from them; that's much different than the kind of forgery prevention I want for my actual bank. (And obviously SPF isn't going to stop mail from bank0vamer1ca.cm etc., but it can cut down some of the noise and leave the rest for Spamassassin.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
AW: AW: SPF Configurations
John, -Ursprüngliche Nachricht- Von: John R. Levine [mailto:jo...@iecc.com] Gesendet: Samstag, 5. Dezember 2009 01:54 An: Andre Engel Cc: nanog@nanog.org Betreff: Re: AW: SPF Configurations Right. The only major mail system that pays attention to SPF is Hotmail, but there are enough small poorly run MTAs that use it that an SPF record which lists your outbounds and ~all (not -all) can be marginally useful to avoid bogus rejections of your mail. For example : [ various large ISPs that publish SPF ] Perhaps this is a language problem. In English, publishes is not a synonym for pays attention to. As I said, you need to publish SPF to get mail into Hotmail. That's why people do it. As I said im almost german :-) Some major providers ,11 for example, assigned their customers the responsibility to pay attention on SPF for getting mails into their boxes.(decision between suspicious or not) I know there is a problem so far with forwarded emails but there is also a solution : [ hoary SRS proposal to change every SMTP server in the world to make them match what SPF does ] Sigh. I do not want to change every SMTP servers in the world. I just gonna show an useful option .-) Every time a mail arrives that is an SRS address the password and timestamp could be checked, and faked or outdated recipients could be rejected. You might want to look at BATV, which has nothing to do with SPF, but I have found is quite useful for recognizing spam blowback. Sure ! For instance If your are providing an mail cluster for your customer bills, a newsletter server or a cooperated mail cluster and you know that you are sending emails only to receivers email boxes BATV is indeed a awesome tool. But if you are performing a shared mail cluster for your webhosting or your Dial in customers which are using for instance some special kinds of mailing lists maybe you need a additional solution. From a reputation perspective Id like the idea to combine a set of anti spam tools if it is useful. Indeed MAAWG is not the badest place to learn about. R's, John PS: This message (including any attachments) is the property of FHE3 and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. Our policy is to send messages with confidentiality notices to all of your competitors. Sure! Im here to learn *** .-) Cheers Andre -- Andre Engel Consulting Program Director, Email and Cyber Intelligence Services..no space left on the device/Kein Weltraum links auf dem Gerät FHE3 GmbHP: +49 721 869 5907 Scheffelstr. 17a M: +49 160 962 44476 76135 Karlsruhe andre.en...@fhe3.com http://www.fhe3.com/ Amtsgericht Mannheim, HRB 702495 Umsatzsteuer-Ident: DE254677931 Geschäftsführer: Peter Eisenhauer, Michael Feger, Dimitrij Hilt *** This email is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE ,...
SPF Configurations
I'm wondering if a few DNS experts out there could give me some input on SPF record configuration. Our company sends out about 50k - 100k emails a day, and most emails are on behalf of customers to their end users at various domains (no, we're not spammers, these are email notifications the end users have requested to receive). Some customers insist on making the FROM address use their domain name, but the emails leave our mail servers on our domain. SPF seems to be the way we could possibly avoid more spam filters, and delivery rate is very important to our company. The server configuration consists of a mail server that sends outbound only, out of a specific IP with proper MX, A, and PTR records. This is a sample of the SPF configuration I believe would be correct: Our company (example.com) records: IN MX 10 mail.example.com mailIN A ip address example.com IN TXT v=spf1 mx -all example.comIN SPF v=spf1 mx -all mailIN TXT v=spf1 a -all mailIN SPF v=spf1 a -all customer.com IN TXT v=spf1 include:example.com -all customer.com IN SPF v=spf1 include:example.com -all Our customer's (customer.com) records: IN MX 10 mail.customer.com mailIN A ip address customer.com IN TXT v=spf1 mx -all customer.com IN SPF v=spf1 mx -all mailIN TXT v=spf1 a -all mailIN SPF v=spf1 a -all customer.com IN TXT v=spf1 include:example.com -all customer.com IN SPF v=spf1 include:example.com -all I derived this from this tutorial: http://www.zytrax.com/books/dns/ch9/spf.html . The other part of this that may be of importance would be the NATing. The FQDN that the world sees for the outside address of the NAT is not the same as the inside FQDN that Postfix is using internally. Does this cause any problems with SPF? Any comments or suggestions would be great. Thanks in advance! Jeffrey
RE: SPF Configurations
Thanks for your input on this. My main concern is mail filters at the end users side thinking that our mail servers are spoofing our customer's domain. I'll check into MAAWG as well Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jne...@billtrust.com -Original Message- From: Joe St Sauver [mailto:j...@oregon.uoregon.edu] Sent: Friday, December 04, 2009 11:25 AM To: Jeffrey Negro Subject: Re: SPF Configurations #Some customers insist on #making the FROM address use their domain name, but the emails leave our #mail servers on our domain. Then your IPs or outbound mail servers should be listed on the customer's SPF record... assuming they also send their own mail, they obviously also want to list their own mail servers. #SPF seems to be the way we could possibly avoid more spam filters, SPF only provides a way of avoiding spoofing, it does not necessarily enhance your IP reputation or your domain reputation #and delivery rate is very important to our company. Are you involved with MAAWG? (see www.maawg.org) Regards, Joe
Re: SPF Configurations
If the customer insist on using their domain, then you would have to have the customer setup an SPF record within their domain that points to your email server IP blocks. I would just tell your customer that if they insist of using their FROM domain, to help get past someone's spamming system the customer is going to have to add the a SPF record to their domain similar to the following: [customer domain].com. IN TXT v=spf1 a mx ip4:[your IP block] Putting an SPF record in your DNS record will have no affect on spamming software. SPF is basically another form of reverse DNS at the mail level. Bret Jeffrey Negro wrote: Thanks for your input on this. My main concern is mail filters at the end users side thinking that our mail servers are spoofing our customer's domain. I'll check into MAAWG as well Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jne...@billtrust.com -Original Message- From: Joe St Sauver [mailto:j...@oregon.uoregon.edu] Sent: Friday, December 04, 2009 11:25 AM To: Jeffrey Negro Subject: Re: SPF Configurations #Some customers insist on #making the FROM address use their domain name, but the emails leave our #mail servers on our domain. Then your IPs or outbound mail servers should be listed on the customer's SPF record... assuming they also send their own mail, they obviously also want to list their own mail servers. #SPF seems to be the way we could possibly avoid more spam filters, SPF only provides a way of avoiding spoofing, it does not necessarily enhance your IP reputation or your domain reputation #and delivery rate is very important to our company. Are you involved with MAAWG? (see www.maawg.org) Regards, Joe
Re: SPF Configurations
2009/12/4 Bret Clark bcl...@spectraaccess.com If the customer insist on using their domain, then you would have to have the customer setup an SPF record within their domain that points to your email server IP blocks. I would just tell your customer that if they insist of using their FROM domain, to help get past someone's spamming system the customer is going to have to add the a SPF record to their domain similar to the following: [customer domain].com. IN TXT v=spf1 a mx ip4:[your IP block] Putting an SPF record in your DNS record will have no affect on spamming software. SPF is basically another form of reverse DNS at the mail level. Bret The problem we face is that some people we work with can't do that, they can't even grasp what an SPF record is and so as far as our own spam filtering goes, we have filtered their emails to us sent with the FROM address being an @mysurname.com domain which doesn't exist and as a result we have filtered out their mails so we have had to lower our SPF checking slightly which is so annoying :S -- Regards, James ;) Charles de Gaullehttp://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html - The better I get to know men, the more I find myself loving dogs.
RE: SPF Configurations
On Fri, 2009-12-04 at 11:45 -0500, Jeffrey Negro wrote: Thanks for your input on this. My main concern is mail filters at the end users side thinking that our mail servers are spoofing our customer's domain. If you really feel that SPF is going to help, then keep all the mail in your domain's control by using VERP addresses as the envelope sender address (like most decent modern MLM packages do). That way you can have a From: header in the customer domain (or of your choosing), and the envelope sender in your own. The benefit here is that not only does it make the usage of SPF a lot less complex, but it also means that all bounces come back to the originating system and can be handled accordingly. Have a look at the headers of this message for a well-formed example. Of course, this does depend upon people believing that SPF is actually useful... Graeme
RE: SPF Configurations
From talking to a few people so far it seems like it might be better to have the development team here alter our applications to use a separate Envelope From and friendly From. I can display the email address with the customers domain, but the mail will be coming from our address as the Envelope From. That way the customer is happy their end user is seeing the email coming from their domain, while the Envelope From shows an email address that matches our domain. Seems like a simpler solution. Thank you all for your input, as I know this may be a bit off topic for this list. Jeffrey -Original Message- From: Graeme Fowler [mailto:gra...@graemef.net] Sent: Friday, December 04, 2009 1:59 PM To: NANOG Subject: RE: SPF Configurations On Fri, 2009-12-04 at 11:45 -0500, Jeffrey Negro wrote: Thanks for your input on this. My main concern is mail filters at the end users side thinking that our mail servers are spoofing our customer's domain. If you really feel that SPF is going to help, then keep all the mail in your domain's control by using VERP addresses as the envelope sender address (like most decent modern MLM packages do). That way you can have a From: header in the customer domain (or of your choosing), and the envelope sender in your own. The benefit here is that not only does it make the usage of SPF a lot less complex, but it also means that all bounces come back to the originating system and can be handled accordingly. Have a look at the headers of this message for a well-formed example. Of course, this does depend upon people believing that SPF is actually useful... Graeme
AW: SPF Configurations
Every time a mail arrives that is an SRS address the password and timestamp could be checked, and faked or outdated recipients could be rejected. If you asked around drawbacks your right : SRS generates very long localparts. Mail servers should according to the RFC accept local parts with at least 63 characters. Most mail servers accept longer local parts, but unfortunately some won't. For those rare cases it is possible to configure a list of mail servers for which SRS won't be accomplished. For rants about how badly the world and/or SPF stink, followups to Spam-L. For proposals about other anti-spam magic bullets, followups to ASRG. Indeed Spam-L is the best place to talk about anti-spam . Indeed CII is the best place to talk about critical infrastructures ,indeed nanog is the best place to talk about networkstuff but we are mostly operators looking for a valuable , comfortable solution to protect and share information . I do not really know if this will be a little off topic . Cheers Andre -- Andre Engel Consulting Program Director, Email and Cyber Intelligence Services..ehy my friend we seek the Grail! FHE3 GmbHP: +49 721 869 5907 Scheffelstr. 17a M: +49 160 962 44476 76135 Karlsruhe andre.en...@fhe3.com http://www.fhe3.com/ Amtsgericht Mannheim, HRB 702495 Umsatzsteuer-Ident: DE254677931 Geschäftsführer: Peter Eisenhauer, Michael Feger, Dimitrij Hilt This message (including any attachments) is the property of FHE3 and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -Ursprüngliche Nachricht- Von: John Levine [mailto:jo...@iecc.com] Gesendet: Freitag, 4. Dezember 2009 18:25 An: nanog@nanog.org Betreff: Re: SPF Configurations If the customer insist on using their domain, then you would have to have the customer setup an SPF record within their domain that points to your email server IP blocks. Right. The only major mail system that pays attention to SPF is Hotmail, but there are enough small poorly run MTAs that use it that an SPF record which lists your outbounds and ~all (not -all) can be marginally useful to avoid bogus rejections of your mail. As everyone here should already know, the fundamental problem with SPF is that although it does an OK job of describing the mail sending patterns of dedicated bulk mail systems, it can't model the way that normal mail systems with human users work. But so deep is the faith of the SPF cult that they blame the world for not matching SPF rather than the other way around, believing that it prevent forgery, having redefined forgery as whatever it is that SPF prevents. As the operator of one of the world's more heavily forged domains (abuse.net) I can report that if you think it prevents forgery blowback, you are mistaken. For rants about how badly the world and/or SPF stink, followups to Spam-L. For proposals about other anti-spam magic bullets, followups to ASRG. R's, John
Re: SPF Configurations
On Fri, Dec 4, 2009 at 9:55 PM, Jeffrey Negro jne...@billtrust.com wrote: I'm wondering if a few DNS experts out there could give me some input on SPF record configuration. Our company sends out about 50k - 100k emails a day, and most emails are on behalf of customers to their end users at SPF records aren't going ot help as much as some list sending and deliverability best practices (feedback loops etc) are. Look at the MAAWG senders best practices document - www.maawg.org - Published Documents Other than delivery to hotmail, spf is a total waste of time - plus it plays russian roulette with whatever email you handle
Re: AW: SPF Configurations
Right. The only major mail system that pays attention to SPF is Hotmail, but there are enough small poorly run MTAs that use it that an SPF record which lists your outbounds and ~all (not -all) can be marginally useful to avoid bogus rejections of your mail. For example : [ various large ISPs that publish SPF ] Perhaps this is a language problem. In English, publishes is not a synonym for pays attention to. As I said, you need to publish SPF to get mail into Hotmail. That's why people do it. I know there is a problem so far with forwarded emails but there is also a solution : [ hoary SRS proposal to change every SMTP server in the world to make them match what SPF does ] Sigh. Every time a mail arrives that is an SRS address the password and timestamp could be checked, and faked or outdated recipients could be rejected. You might want to look at BATV, which has nothing to do with SPF, but I have found is quite useful for recognizing spam blowback. R's, John PS: This message (including any attachments) is the property of FHE3 and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. Our policy is to send messages with confidentiality notices to all of your competitors.
Re: SPF Configurations
On 2009-12-4, at 7:25, John Levine wrote: The only major mail system that pays attention to SPF is Hotmail FWIW, GMX (pretty popular in Europe) does too. Lars smime.p7s Description: S/MIME cryptographic signature
Re: SPF Configurations
Jeffrey Negro wrote: SPF seems to be the way we could possibly avoid more spam filters, and delivery rate is very important to our company. You've seen the anti-SPF rants. At the least, they should make clear to you that you should use SPF only and exactly for specific destinations that you already know require it. If you have any doubts about the requirement, you'll try to verify it; otherwise assume SPF won't solve your problems. The other obvious mechanisms for validated identification to receiving operators is, of course, with DKIM. DKIM is entirely comfortable having a validated identifier (the d= parameter in the signature header field) be different than whatever is in the author header field (From:) But either way, that's just identification. As already noted on the thread, what matters most is the set of content and operations practices, to establish a rock solid reputation both of you and of your clients. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
