Re: BGPMON Alert Questions
Yes, we don't validate those prefixes cause we filter them strict. in our measurements, an rpki-based origin check is significantly faster than an acl of non-trivial length. randy
CVE-2014-0160 mitigation using iptables
Following up on the CVE-2014-0160 vulnerability, heartbleed. We've created some iptables rules to block all heartbeat queries using the very powerful u32 module. The rules allow you to mitigate systems that can't yet be patched by blocking ALL the heartbeat handshakes. We also like the capability to log external scanners :) The rules have been specifically created for HTTPS traffic and may be adapted for other protocols; SMTPS/IMAPS/... # Log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ 52=0x1803:0x1803 -j LOG --log-prefix BLOCKED: HEARTBEAT # Block rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ 52=0x1803:0x1803 -j DROP # Wireshark rules $ tshark -i interface port 443 -R 'frame[68:1] == 18' $ tshark -i interface port 443 -R 'ssl.record.content_type == 24' We believe that this should only be used as a temporary fix to decrease the exposure window. The log rule should allow you to test the firewall rules before being used in production. It goes without saying that if you have any suggested improvements to these rules we would be grateful if you could share them with the security community. Clearly, use of these rules is at your own risk ;) ECSC SOC Team Researchers: Adam Shore Alex Innes Fabien Bourdaire -- ECSC Ltd - http://www.ecsc.co.uk
Re: procmail, was autoresponding to Yahoo DMARC breakage
On 4/9/2014 9:21 PM, George Michaelson wrote: Aside from a horrid config notation. the main problem for me has always been getting sysadmins to include the changes which expose envelope-sender and envelope-recipient to procmail. Thats not procmail, its the way procmail is typically called. Without it, some stuff simply cannot be done because you don't know the values passed by protocol, only the values exposed in header. (this may have changed. I don't use it any more) It can still be a problem, although I believe LMTP fixes this problem along with the others it was designed to fix. Jack
Re: BGPMON Alert Questions
On Thursday, April 10, 2014 09:18:34 AM Randy Bush wrote: in our measurements, an rpki-based origin check is significantly faster than an acl of non-trivial length. Ultimately, at some point in the future, it is not completely unreasonable to think that some operators could attempt control plane filtering based purely on RPKI-based origin and AS_PATH validation, without actually needing to configure prefix or AS_PATH lists :-). Wouldn't that be something... Mark. signature.asc Description: This is a digitally signed message part.
Re: CVE-2014-0160 mitigation using iptables
On 09/04/2014 11:07, Fabien Bourdaire wrote: Following up on the CVE-2014-0160 vulnerability, heartbleed. We've created some iptables rules to block all heartbeat queries using the very powerful u32 module. as someone pointed out on the UKNOF mailing list yesterday, you make a number of assumptions in this ruleset which are not necessarily valid. Please do not claim that this ruleset blocks all heartbeat queries because it does not. Nick
re: Yahoo DMARC breakage
at some point, Dave Crocker wrote: If I point a gun at you, and pull the trigger, but maybe shouldn't have done that, the gun is not broken. It occurs to me that, if you point a gun at me, aim at me, pull the trigger, and hit someone standing 10 feet to my left - the gun IS broken (or at least very poorly designed). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra re
Re: procmail, was autoresponding to Yahoo DMARC breakage
All this talk about procmail leads me to ask: - has anybody come up with a procmail recipe, or other mechanism to validate DKIM-signed mail and apply an Original-Authentication-Results header, at the MTA level? - if so, does it work with Yahoo mail directed to mailing lists? - if yes, can you share?! (So far, all the folks I know who are trying to react, have been doing so via hacks to their list management software. I'm hoping to attack the problem at a more accessible step in mail processing). -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: Yahoo DMARC breakage
Tei wrote: Your post advocates a (*) technical ( ) legislative ( ) market-based ( ) vigilante approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular (*) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down! Right about now, I'm starting to lean toward: (*) Nice try, assh0le! I'm going to find out where you live and burn your house down! Foisting this on the world, particularly as tax day approaches - heads should roll. Sigh... Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: BGPMON Alert Questions
as folk start to roll out rejection of invalids, we might think about how we report problems with folk registering inadequate roas, covering their customers, covering their deaggs (maybe deaggs get what they deserve), etc. if they are not clued enough to generate prudent roas, they will not be clued enough to generate ghostbusters (and neither ripe's nor apnic's software supports gbrs today). if my customer can not reach foo's customer, will foo's rir be willing to help? if foo's customer can not reach mine, how to let foo know who to call/write? do we need conventions? randy
Re: Yahoo DMARC breakage
An aside: On Wed, Apr 09, 2014 at 05:15:59PM -0400, William Herrin wrote: Maybe this is a good thing - we can stop getting all the sorry I'm out of the office emails when posting to a list. I entirely support that goal, but my preferred solution is the complete eradication of the software (a lot of which makes mistakes that have been well-known as mistakes for decades) and thus the entire practice of setting up out of office messages. Out-of-office notices might have had some relevance 20 or 30 years ago when much of the population was new to email and had not yet grasped in *any* sense how it works. And when there was a large overlap between people who use email and people who read/send email from their offices and only from their offices. But I think by now everyone who is capable of being educated has been educated and realizes that the one of the reasons for the absence of a response is that the recipient hasn't seen the relevant message yet. There's really no need to spin the roulette wheel and hope that the combination of MUAs and MTAs on both ends is functional enough to enable the out-of-office software (optimistically presuming it's halfway sane) to figure out what it should do. And that's before we even get to the security and privacy issues that are in play, which are substantial. So while there are numerous approaches to solving the problem of errant out-of-office messages, and some of those approaches work pretty well in the field, I would prefer to kill the problem by attacking the source: the *existence* of out-of-office autoresponders. ---rsk
Re: Yahoo DMARC breakage
I agree to a large extent with your comments/observations, but I'd like to focus on one point in particular: On Wed, Apr 09, 2014 at 11:00:57PM -0400, Andrew Sullivan wrote: So, I'm trying to imagine the presentation slide on which appears the advice to implement the controversial adopted policy. I imagine in big, giant print Will reduce yahoo.com abuse effects and in one of those secondary bullets May have consequences and even lower for our users on mailing lists and for mailing list managers/non-company. This decision by Yahoo will have no effect whatsoever on the largest abuse problem, which is outbound spam/phishing/malware/etc. *sourced* by Yahoo. Those messages are (and have been for a long time) dutifully marked as authentic and in one sense they are: they really do originate from Yahoo's operation. But of course in a much more important operational sense they're not: they're forgeries created by the new owners of hijacked Yahoo user accounts. And those accounts are being hijacked at will by the millions, as they have been for many years. Yahoo is not alone in permitting an enormous volume of such messages to leave their operation and attack the rest of the Internet: Hotmail, Gmail, and the rest do the same. (Of course the rates vary, as do the targets. My spamtraps see large rate fluctuations across networks, domains, ASNs, etc. as well as through time. I strongly suspect that individual measurements at any one are essentially meaningless and that aggregation over a sufficiently diverse set over a sufficiently long time is necessary to construct a coherent, useful statistical model of what's really happening.) In other words, this deployment might reduce abuse OF Yahoo, but it will do nothing about the far more important problem of abuse BY Yahoo. Which pretty much lives up to my expectations. ---rsk
Re: Yahoo DMARC breakage
On 4/9/2014 11:54 PM, Jimmy Hess wrote: Basic functionality is seriously and utterly broken --- that DMARC doesn't have a good answer for such situations, is a major indicator of its immaturity, in the sense that it is Too specific a solution and cannot apply to e-mail in general. If it were mature: a mechanism would be provided that would allow mailing lists to function without breaking changes such as substituting From:. On 4/9/2014 11:54 PM, Jimmy Hess wrote: Basic functionality is seriously and utterly broken --- that DMARC doesn't have a good answer for such situations, is a major indicator of its immaturity, in the sense that it is Too specific a solution and cannot apply to e-mail in general. If it were mature: a mechanism would be provided that would allow mailing lists to function without breaking changes such as substituting From:. Every tool has limitations. An 18-wheeler truck is not broken or immature because it fails to corner like a Maserati. A Maserati is not broken or immature because it does not have the carrying capacity of an 18-wheeler. DMARC was designed to handle a particular usage scenario and its limitations have been carefully documented. Or perhaps we need to declare email broken and immature because it does not (yet) satisfy a long list of entirely reasonable functional requirements, such as, ummm, author authentication? Long deployment and use and deep knowledge don't matter; only satisfying someone's list of requirements does? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yahoo DMARC breakage
On 4/10/2014 5:05 AM, Tei wrote: Your post advocates a (*) technical ( ) legislative ( ) market-based ( ) vigilante Since the nanog list isn't devoted to anti-spam work, folk might not know that you were calling upon the stellar web page developed by Cory Doctorow: http://craphound.com/spamsolutions.txt As far as I know, he meant it strictly for humor. However he did such a good job, it is common to point folk to it (or, as we've seen here, even fill it out) when the they declare that they have the FUSSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: BGPMON Alert Questions
On Thursday, April 10, 2014 12:30:51 PM Randy Bush wrote: as folk start to roll out rejection of invalids, we might think about how we report problems with folk registering inadequate roas, covering their customers, covering their deaggs (maybe deaggs get what they deserve), etc. if they are not clued enough to generate prudent roas, they will not be clued enough to generate ghostbusters (and neither ripe's nor apnic's software supports gbrs today). Agree. If you are clued enough to generate ROA's, you are clued enough to generate ROA's for the de-aggregates (or, at least, respond to the errors that indicate that). But the reverse is also true. It would be useful to use BGPmon's free RPKI validation feature, which e-mails you, incessantly, about validation failures due to un-ROA'd de-aggregates. It will also help if the CA's run by the RIR's support prefix length definitions. For the Africa region, AFRINIC currently do not, meaning every de-aggregate needs to be ROA'd. It's planned, though... if my customer can not reach foo's customer, will foo's rir be willing to help? if foo's customer can not reach mine, how to let foo know who to call/write? do we need conventions? This was one of the questions I've always pondered, and if you recall, was part of our panel discussion on the subject in Xi'an last year. I think it would be helpful if CA delegation was supported by RIR's, and supported well, so that customers can deal with their ISP's CA instead of having to deal with the RIR instead (particularly for situations where RIR's aren't 24/7 shops). On the monitoring side, it will be critical for ISP's to provide looking glasses that customers can use to verify the delta between what has been ROA'd and what has been announced/rejected, particularly in the case of un-ROA'd de- aggregates. Mark. signature.asc Description: This is a digitally signed message part.
Re: Yahoo DMARC breakage
On 4/10/2014 5:13 AM, Miles Fidelman wrote: If I point a gun at you, and pull the trigger, but maybe shouldn't have done that, the gun is not broken. It occurs to me that, if you point a gun at me, aim at me, pull the trigger, and hit someone standing 10 feet to my left - the gun IS broken (or at least very poorly designed). Unfortunately, that has no relationship to do with the current situation. Again: Yahoo was fully aware of the implications of its choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: CVE-2014-0160 mitigation using iptables
On Wed, 09 Apr 2014 11:07:36 +0100, Fabien Bourdaire said: # Log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ 52=0x1803:0x1803 -j LOG --log-prefix BLOCKED: HEARTBEAT That 52= isn't going to work if it's an IPv4 packet with an unexpected number IP or TCP options, or an IPv6 connection pgpSHCF2kY9zz.pgp Description: PGP signature
RE: CVE-2014-0160 mitigation using iptables
He was also proven wrong on the Full Disclosure list but he seems to be pushing this everywhere he can find an audience for some reason. -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Thursday, April 10, 2014 6:13 AM To: Fabien Bourdaire; nanog@nanog.org Subject: Re: CVE-2014-0160 mitigation using iptables On 09/04/2014 11:07, Fabien Bourdaire wrote: Following up on the CVE-2014-0160 vulnerability, heartbleed. We've created some iptables rules to block all heartbeat queries using the very powerful u32 module. as someone pointed out on the UKNOF mailing list yesterday, you make a number of assumptions in this ruleset which are not necessarily valid. Please do not claim that this ruleset blocks all heartbeat queries because it does not. Nick
Re: Yahoo DMARC breakage
On 04/09/2014 09:54 PM, Jimmy Hess wrote: Basic functionality is seriously and utterly broken --- that DMARC doesn't have a good answer for such situations, is a major indicator of its immaturity, in the sense that it is Too specific a solution and cannot apply to e-mail in general. DMARC is nothing more than warmed over ADSP which itself didn't have a pat answer for mailing list traversal. For transactional mail ADSP was just fine, but for regular mail the signing policy was meant to be a guide for other heuristics. It says nothing more than i sign my mail outgoing, so what do you do if the signature is broken? If you want to take a hard line, then you are going to get all kinds of false positives... this has been known for 10 years at least. I'd be surprised to hear that Y! of all people was doing that, but it's their pissed off users' problem. Vote with your feet. If it were mature: a mechanism would be provided that would allow mailing lists to function without breaking changes such as substituting From:. An example of a solution would be the use of a DKIM alternative with not a single signature for the entire message, but only partial signing of parts of the message: specifically identified headers and/or specific body elements, to validate that the message was really sent and certain elements are genuine and certain elements were modified by the mailing list. You can more or less do this with DKIM already, and get about 90% of mailing list traffic to pass verification. The question is whether that's enough. I have no idea whether Y! is doing the things I did to get that pass rate. The technical issue, is that the immaturity of the related specs. limits the decisions are available for a particular domain so, essentially, if you have certain kind of user traffic: you have to incur technical issues with mailing lists, or forego using DMARC. In other words: much as you would like to dismiss as purely a managerial decision the decisions available to be made are entangled with the limitations of the technical options that are available for mitigating spoofing, AND the public's understanding thereof. Crocker may have some further insight that we're not privy to, but using signing policy on the general population as a raw instrument is well known to be a bad idea for DKIM and SPF's policy mechanisms as well. SPF in particular had a huge amount of blowback by punitive mail operators who didn't understand the implications, at least in the early days. It may indeed be management idiocy, but I can't see what the point is in defending the idiocy as being some sort of sacred right. Mike
Re: Yahoo DMARC breakage
On Thu, 10 Apr 2014 07:56:16 -0700, Michael Thomas said: but I can't see what the point is in defending the idiocy as being some sort of sacred right. I'm sure Randy Bush would defend his competitor's right to run their networks that way. :) pgpPc4rzVLYWF.pgp Description: PGP signature
ICANN issues call for public input on process to develop IANA stewardship transition plan
NANOGers - As you may have heard, the United States National Telecommunications and Information Administration (US NTIA) has a contract with ICANN for administration of the Internet technical identifiers [e.g. DNS names, IP address spaces, and protocol parameters], and recently proposed transitioning stewardship of these tasks over to the Internet technical community. ICANN is facilitating the development of a plan to accomplish this, and their initial draft of a process for plan development has been released and is available for public comment. Comments on the proposed process are due by 8 May 2014, and as that is well before NANOG 61 in June, I'm drawing attention to this opportunity via the list. You can find more information regarding the proposed process and how to provide feedback attached. FYI (and thanks!) /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN i...@arin.netmailto:i...@arin.net Subject: [arin-announce] ICANN issues Call for Public Input on the IANA Functions Transition Date: April 9, 2014 at 12:41:18 PM EDT To: arin-annou...@arin.netmailto:arin-annou...@arin.net ICANN has issued a call for public input on a newly released Draft Proposal, based on initial community input, of the principles, mechanisms, and process to develop a proposal to transition NTIA's stewardship of the IANA functions. Details are available at: http://www.icann.org/en/about/agreements/iana/transition/draft-proposal-08apr14-en.htm Feedback can be submitted via the publicly archived mailing list: ianatransit...@icann.org. We encourage ARIN community members to participate, and call to your attention that the deadline to contribute is 8 May 2014 (midnight UTC). Regards, Communications and Member Services American Registry for Internet Numbers (ARIN)
Re: Yahoo DMARC breakage
On 04/09/2014 06:04 PM, Miles Fidelman wrote: Especially after reading some of the discussions on the DMARC mailing list where it's clear that issues of breaking mailing lists were explicitly ignored and dismissed. There's been 10 years of ostrichism about policy and mailing lists, especially from the crowd who were against ADSP until they were for it. Mike
Re: CVE-2014-0160 mitigation using iptables
On Thu, Apr 10, 2014 at 9:52 AM, valdis.kletni...@vt.edu wrote: On Wed, 09 Apr 2014 11:07:36 +0100, Fabien Bourdaire said: # Log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ 52=0x1803:0x1803 -j LOG --log-prefix BLOCKED: HEARTBEAT That 52= isn't going to work if it's an IPv4 packet with an unexpected number IP or TCP options, or an IPv6 connection IPv6 wasn't mentioned here (that'd be ip6tables). But yeah, there might be some other shortcomings with the match. I think it's the right way to go - it just needs a bit of work (maybe a bm string match?). You're also going to deal with different versions (see ssl-heartbleed.nse for the breakdown). Though, I wonder if there are any other variations you might miss...
Akamai DNS for GoDaddy hosted servers?
Anyone else hosting at GoDaddy seeing NXDOMAIN from some Akamai servers? Example: # dig +trace ip-redacted.ip.secureserver.net ; DiG 9.9.5 +trace ip-redacted.ip.secureserver.net ;; global options: +cmd snip secureserver.net. 172800 IN NS cns1.secureserver.net. secureserver.net. 172800 IN NS cns2.secureserver.net. secureserver.net. 172800 IN NS a9-67.akam.net. secureserver.net. 172800 IN NS a8-67.akam.net. secureserver.net. 172800 IN NS a1-245.akam.net. secureserver.net. 172800 IN NS a20-65.akam.net. secureserver.net. 172800 IN NS a11-64.akam.net. secureserver.net. 172800 IN NS a6-66.akam.net. snip # dig ip-redacted.ip.secureserver@cns1.secureserver.net ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28818 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5 ;; WARNING: recursion requested but not available snip ;; ANSWER SECTION: ip-redacted.ip.secureserver.net. 3600 IN A REDACTED ;; AUTHORITY SECTION: ip.secureserver.net.3600IN NS cns2.secureserver.net. ip.secureserver.net.3600IN NS cns1.secureserver.net. snip # dig ip-redacted.ip.secureserver.net @a9-67.akam.net snip ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 56606 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip-redacted.ip.secureserver.net. INA ;; AUTHORITY SECTION: secureserver.net. 3600IN SOAcns1.secureserver.net. dns.jomax.net. 2014041000 300 600 2592000 3600 ;; Query time: 13 msec ;; SERVER: 184.85.248.67#53(184.85.248.67) ;; WHEN: Thu Apr 10 09:11:21 PDT 2014 ;; MSG SIZE rcvd: 115
Re: Yahoo DMARC breakage
On 10 Apr 2014, at 9:49, Dave Crocker wrote: Unfortunately, that has no relationship to do with the current situation. Again: Yahoo was fully aware of the implications of its choice. I suspect they looked at the amount of spam they could stop, the number of Yahoo email users, and the number of Yahoo users using mailing lists, and said That's just noise, it doesn't matter. It happens to be very loud noise, but it's still tiny compared to the overall number of email users.
ARIN 33 Chicago - 14 proposed changes to IP address policy (non-attendee options)
NANOGers - There are a particularly large number of proposed changes to Internet number resource policy that will be discussed next week at the ARIN 33 meeting in Chicago, and for those who will _not_ be attending, there are still two good options for providing input on these potential changes: 1) Express your support or opposition (and reasoning if possible) on any of the proposed changes on the ARIN Public Policy Mailing List (ppml) 2) Participate remotely in the discussion at the ARIN 33 meeting (remote participants can view the real-time feed, make statements, ask questions, and participate in polls on proposals just as those on-site) Participants must register to participate on-site or remotely in the meeting. You can find information on the proposals and posting comments to arin-ppml here - https://www.arin.net/policy/proposals/ For information on being a remote participant in the ARIN 33 meeting - https://www.arin.net/ARIN33_remote There is also an ARIN 33 discussion guide with all of the proposals, their associated staff/legal reviews, and the current policy manual and policy development process - https://www.arin.net/participate/meetings/reports/ARIN_33/materials/discussion-guide.pdf ARIN administers the number resources in the region in accordance with policy developed by community; participation is open to everyone and improves the quality of the resulting policy that we must follow. Thanks! /John John Curran President and CEO ARIN
Re: BGPMON Alert Questions
On Thu, Apr 10, 2014 at 9:26 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Thursday, April 10, 2014 12:30:51 PM Randy Bush wrote: as folk start to roll out rejection of invalids, we might think about how we report problems with folk registering inadequate roas, covering their customers, covering their deaggs (maybe deaggs get what they deserve), etc. if they are not clued enough to generate prudent roas, they will not be clued enough to generate ghostbusters (and neither ripe's nor apnic's software supports gbrs today). snip It would be useful to use BGPmon's free RPKI validation feature, which e-mails you, incessantly, about validation failures due to un-ROA'd de-aggregates. This seems like good idea and would also be good to know how else to know I've broken something.. There's a BGP Visibility Project http://visibility.it.uc3m.es/ which perhaps could be brought to bear. Other thoughts out there? Tony
Re: Yahoo DMARC breakage
Andrew Sullivan asulli...@dyn.com writes: I think DMARC is mostly useful when used correctly. There is no BCP yet... There is, however, BCP167/RFC6377 covering DKIM and mailing lists. Some relevant sections are 4.1 and 5.3: 4.1: ... site administrators wishing to employ ADSP with a discardable setting SHOULD separate the controlled mail stream warranting this handling from other mail streams that are less controlled, such as personal mail that transits MLMs [Mailing List Managers]. 5.3: At subscription time, an ADSP-aware MLM SHOULD check for a published ADSP record for the new subscriber's domain. If the policy specifies discardable, the MLM SHOULD disallow the subscription or present a warning...
ID10T out of office responders (was Re: Yahoo DMARC breakage)
On 4/10/2014 6:29 AM, Rich Kulawiec wrote: On Wed, Apr 09, 2014 at 05:15:59PM -0400, William Herrin wrote: Maybe this is a good thing - we can stop getting all the sorry I'm out of the office emails when posting to a list. I entirely support that goal, but my preferred solution is the complete eradication of the software (a lot of which makes mistakes that have been well-known as mistakes for decades) and thus the entire practice of setting up out of office messages. [relevant discussion] But I think by now everyone who is capable of being educated has been educated and realizes that the one of the reasons for the absence of a response is that the recipient hasn't seen the relevant message yet. There's really no need to spin the roulette wheel and hope that the combination of MUAs and MTAs on both ends is functional enough to enable the out-of-office software (optimistically presuming it's halfway sane) to figure out what it should do. And the truly paranoid that are scared to death that nobody will miss them, have learned to forward the flow to a device that is never out of the office. (I have filters on the two accounts whose mail I EVER read that forward mail from named sources to my BlackBerry. My Kindle gets copies af all mail sent to those two accounts (mostly since I have been to lazy to set up the filtered stream and I almost never look at it anyway). And that's before we even get to the security and privacy issues that are in play, which are substantial. And that is where I started. In every other part of my life the conventional wisdom has been do NOT put a thing on the Sassiety page about your up-coming around-the-world cruise and the camera equipment you have bought for the trip, Leave lights and a radio on timers, stop the mil and the newspapers, get somebody to mow the lawn and pick up the trash every few days, have somebody down the street park their car in your drivewayand so on. Why on G*ds blue Earth would I want put up posters and flyers that say need a stapler? I just got a new one., I won't be looking for my desk chair for a while., and If your keyboard fails,..? So while there are numerous approaches to solving the problem of errant out-of-office messages, and some of those approaches work pretty well in the field, I would prefer to kill the problem by attacking the source: the *existence* of out-of-office autoresponders. Amen -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
