I've gone in for a bit of mystical-appearing troubleshooting myself. A different time, the same company: there was a box showing erratic symptoms. I felt sure it was bad RAM. (The techs who were already on-site had been looking for software problems, and I felt sure they'd checked everything quite thoroughly.) I noticed while it was booting that HIMEM.SYS gave the message, "Bypassing memory test". (There's a flag in config.sys to make it do that. The default-- at least back then, I have no idea about today-- is to briefly test the RAM.)
Well, the error was pretty prominent. I felt that even HIMEM's simple memory test would find it. Me, I had just finished my lunch-- carry-out chicken from down the street. I even still had the carry-out box in my hand. It was too good of an opportunity to pass up.
I laid out some scratch paper on the user's desk. Then I took my box of chicken bones, and shook them over the computer, muttering "Foo mane padme hum". Then I dumped the chicken bones onto the paper, and studied them for a moment.
"Now the problem may be seen," I pronounced. I rebooted the computer, and subtly held down the left shift key. Some techs may remember, among other things, this would cause the on-disk config.sys to be ignored, and a default loaded-- one that lets himem.sys test the memory.
Sure enough, it reported the failure.
A different company. I was working the phone lines for tech support. The only other guy on support-- a buddy of mine from way back who happened to get hired there-- was green as can be; the company didn't even bother to train him on our product.
He comes to my desk in a hurry. He had a customer who couldn't install our product. He hurredly described the symptoms. I told him to instruct the customer thusly: take the disk, and hold it vertically. As if the disk were a knife, and you were trying to cut the desk, rap the disk against the desk three times. Then try the install again.
The poor fella looked like I had gone insane. "The customer's on the line right now," he said. "This is no time for jokes; I need a real answer!" I refused to tell him any more until he told the customer what I said. He went back to his desk. I could hear him start talking to the customer: "I'm real sorry, but..."
When he came back a few minutes later, his eyes were as wide as saucers. It had worked, the customer was happy. What was all that about?
I explained that there was a bit of dust on the disk surface.
I've done exactly that. Broken computer. I was called to investigate. The low-level techs on the scene briefed me, and said that a cold boot had no effect.
I told them exactly what Knight (according to the koan) had said, word-for-word. Then I power-cycled the box and held my breath.
It worked. I smiled, bowed, and walked away.
Of course the low-level techs asked with incredulity why it started working. (They saw the whole thing.) I refused to elaborate, mostly because I had no clue myself.
When I was in tech support, I loved working with military customers. You tell them, "Do this. Now do that and read me the response." They do this, then that, and read you the response. They don't question your judgement or instructions, and are always very courteous. Many will ask questions if they need additional information or something, but they do what the tech requests.
Usually.
I had a call from one net admin who, while clearly quite knowledgable about Unix (our product) and TCP/IP, was having problems getting a particular BIND setup working. We worked through the problem, and he did everything I asked, and we quickly resolved the problem to a misconfigured slave server that had become lost.
But after we solved that, a "dig" from my end showed very different IPs on that domain's servers than the ones he had read me. I said, "Something's still wrong, I'm seeing such-and-such IP." He sheepishly admitted that the IPs I were seeing were the genuine ones, and the ones he was telling me were bogus. I was quite surprised he had kept up the charade, reading me configs and swapping the bogus IPs for the real ones without hesitation or delay.
My boss had somebody try to pull the same stunt with him once, but much more obviously. "What's the IP," he asked. "Let's say it's..." began the customer. "No, none of this make-believe, I really need your IP." (Our product adhered to a CIDR requirement that the subnet part of an address not be all zeros or all ones, so the actual IPs are really significant.)
But by and large, military are my favorite people to support.
I worked for a mom-and-pop computer store. Got in a new design of joystick. We were going to put it on a display computer, so I open the box, and the unit is broken. The stick lolls over to the side. One of the springs that holds it upright had failed. (Insert juvenile jokes here.)
I call Logitech. The tech asked me, "Did you try it on another computer?" I patiently explained that the problem was mechanical, and was clearly not a computer issue.
"Well, try it on a different computer." I explained the problem again, careful to be clear and precise.
"Alright, then, try it on a different computer." I clarified that the joystick had never been plugged into any computer. Ever (at least not since it entered the shop). I was completely aware of the defect from the moment I removed the joystick from the box. It had never been attached to any computer.
I might not throw that out immediately. The support tech clearly didn't know anything about SCSI vs IDE, but I wouldn't be surprised if he had heard an explaination from someone who did.
Harmonics are a wave phenomenon. Many wave pheonmena-- particularly signal reflection-- are problematic in HDD transmission lines. SCSI has traditionally been more careful about controlling wave artifacts than IDE has, and so was able to get higher bitrates than IDE and its precursors for most of their respective lives. On file servers, bitrates are a big deal.
So there may be a nugget of truth in the tech's response, possibly passed down from a SCSI guru to a random guy to your tech, and lost its meaning a long time ago.
I'm not saying it's for sure, just saying there's potential there.
I thought about this for a moment, and realized I live in area code 408. Bummer. Come to think of it, Silicon Valley just can't use this: our A/Cs are 408, 650, and 415.
Please do not take any action that would result in DMCA-type laws being passed in Austrailia. I've always felt that I can move to Austrailia if things get too bad to stay here in America. I'd hate to see things get bad there too.
The big problem I see in spamland today isn't the classification technology.
It's the word recognition problem. Sure, "VIAGRA" may be deeply embedded in a "spam" cluster,
but what about "V1_4G ra"? If spammers weren't
disguising their words, I think that Bayesian filtering and
other techniques work fine. I'm not really sure that
more advanced techniques in word classification are really needed here.
Or is it? Wouldn't it be advantageous to the FBI, et al, to release redacted documents without anyone knowing just how much was redacted?
In some circumstances, perhaps. Moreso, it would be advantageous to the FBI to never release anything. But in an open society, that is contrary to the public interest. The needs need to be balanced.
This idea needs refinement. You don't want five pages of text being the same length as a single sentence, because it's important for the public to know how much of the document is being withheld.
I never understood this behaviour anyway. Why show a person on TV that obvoiously not want to be recoznized (however carefully concealed by the production)?
Thursday I saw a documentary about two guys fighting over a baseball. One of them often went to court and made other public appearances with his grilf. The grilf, at the last minute, decided that she didn't want to be shown in the documentary. But she was in all the footage, so they pixelled her out.
Nobody cared about her face. We care about everything else in the film. Extend this concept.
The following, found during a routine review of our authentication system, are insecure and should never be used:
accounting
admin
backup
boss
cisco
congress
death
engineer
ibm
internet
kiddie
love
manager
sex
snake
user
windows
www
Avoid anything on this list. Any personell using anything on this list will be required to attend a mandatory fnord security training class, and may possibly face reprimands for repeat offenses.
And it's not entirely accurate. For example, I might assert that there's a computer disk with a program on it that solves the halting problem. You can prove that it doesn't exist through pure mathematics.
The idea that "you can't prove a negative" generally comes from the concept of a null hypothesis in statistics. Suppose that I want to demonstrate that caffiene affects you metabolism. My null hypothesis is the opposite: that the metabolism of persons who ingest caffiene is the same as persons who don't. My null hypothesis is one which states that a difference does not exist.
Now, I test a bunch of people: my control group doesn't injest caffiene, and my test group does. I then measure their metabolisms. I observe that the test group has heightened cardiovascular activity. So my null hypothesis has been rejected, thus the alternative hypothesis-- that there is an effect-- is justified.
Had I not seen any effect, then the null hypothesis would not have been proven. We merely would have failed to reject it. Perhaps there is an effect that we did not measure, for instance.
I read an article somewhere about faxing carbon paper (all black) continuously by taping 2 sheets of it together in a loop so it would go on and on and waste all their ink.
I'd recommend against carbon paper, since the carbon dust might get on the lens, in the gears, etc and pretty much waste your fax machine. But other things might work well. For an example, take some of his spam and print it out in white-on-black. Be sure to use a callout box for the bit that says effectively "You asked for this!"
Re:Relocation would be nice...
on
Koalas Gone Wild
·
· Score: 2, Funny
(Brushfires to US readers.. though I agree with a slashdot poster of a few months back, who thought that brushfire sounded like a problem caused by overactive grooming...).
And what do you think 'bushfires' sounds like to us yanks?
There's many ways to do that-- google for "chaffing and winnowing". Briefly, you chunk the data, stick a MAC at the end of each chunk, and use a different MAC key for each thing you want as a possibility.
These schemes they tend to be obvious from the message length, and the algorithms are almost always designed to support it. When the NSA tech sees you're using a chaffing and winnowing (or similar) algorithm, it's a good guess that you've got another message.
Related, we have steg, which hides messages in other messages. But your outer message needs to be of a sort that has a lot of nearly-redundant data so some can be changed for the hidden message. For example, a soldier deployed to Tunis signed his letters with a different middle initial to tell his family where he was, and still get past the censors. (The letters arrived out of order, and his family wondered where "Nutsi" was.) Modern-day steg typically does things like flip low-order bits of photos, but is often detectable.
If your user account is compromised, you can be tricked into running a different program than you intend.
If my user account is compromised, then I don't really need to be tricked; the attacker can just run the programs directly. Or if he's trying to spoof a password prompt, he can edit my.profile and set my PATH to whatever he wants anyway.
Alternately, if you mess up the permissions on your ~, you can be made to run a different program, compromising the account.
Again, if ~ has bad perms, then the attacker can edit my.profile, so again it's irrelevant what I set my PATH to.
If you disable it in your X config, apps can intercept it, so it's foolish to assume that you're looking at a genuine X/K/GDM after hitting it.
Uh... If the X config has been edited, then that means that root was already compromised. Besides, you can see the monitor mode switch if you hit a C-A-BS and it takes effect.
Except it doesn't log out. It just kills everything very nastily.
Not too nastily. Less nastily than a kill -9, for sure. The apps still can do whatever shutdown operations they need to.
But let me paint you a picture. A lab where most of the occupants aren't Unix people. Some of them aren't really computer people. They're hardware designers, or embedded systems programmers, or {domain} experts, or other such things. All of them are good at what they're hired for, but may not be good at other stuff. Like using a PC.
Most of these people got their.profile and.xsession by copying somebody else's, if they're not just using the system default. They didn't pick their WM, because they don't really care much about their WM. They've never taken time to learn anything. They have their xterm start up when they log in, and a row of CDE-style buttons to launch other xterms, a web browser, and maybe Citrix. No easy button to log out.
So they'll often log into a box, do what they need, then wander over to some piece of equipment they need to work on, without logging out. There's only six general-purpose PCs in the lab, so it doesn't take long before they run out if people stay logged in when they're not using them There's a new threat: people hitting the Reset switch when they come across a logged-in but unoccupied machine.
Now, the lab manager needs to make a notice to log out. If there aren't concise, clear instructions on lab notices, they don't get followed. So that's the notice.
Now the other end. What's the harm? Apps still get their notice to shut down. They can save user configs, send termination notices to network peers, whatever they need to do as long as it doesn't involve interaction with the X server.
Sure, it'd be nice if everybody knew all about the tools they used. Hell, it'd be nice if they had basic understanding of their WMs. But they don't, and we don't expect most of them to any more than we expect them to play a trumpet. It's just not what they need to do for their job.
I'm assuming you're referring to the UNCG link, which is clearly discussing university policy. The university falls under both the federal and state government agency rules. (Federal because it's receiving US DofEd funding, and state because it's UNC, for pete's sake.) Note that the bit of law they quote at the bottom only applies to government agencies.
And, if your landlord doesn't want to do business with you because you won't give your social, get 'em prosecuted for it. The link clearly states giving up a social security number must be voluntary.
Which link are you talking about? The first one is only discussing University policy, and the second says almost the opposite. While technically it's voluntary, a private business doesn't have to do business if you don't give 'em your SSN. Read the otherlink, the one from the Social Security Administration:
If a business or other enterprise asks you for your Social Security number, you can refuse to give it to them. However, that may mean doing without the purchase or service for which your number was requested.
Perhaps a HUD apartment couldn't ask for your SSN, but I know of no reason a random landlord couldn't.
And as Detritus pointed out, some entities-- such as employers, banks, and others-- may legitimately require your SSN before they're legally allowed to do business with you. For example, employers and banks need your SSN to file reports with the IRS.
Slashdot Mirror
"You had cold hands"
That's good, I like that.
I've gone in for a bit of mystical-appearing troubleshooting myself. A different time, the same company: there was a box showing erratic symptoms. I felt sure it was bad RAM. (The techs who were already on-site had been looking for software problems, and I felt sure they'd checked everything quite thoroughly.) I noticed while it was booting that HIMEM.SYS gave the message, "Bypassing memory test". (There's a flag in config.sys to make it do that. The default-- at least back then, I have no idea about today-- is to briefly test the RAM.)
Well, the error was pretty prominent. I felt that even HIMEM's simple memory test would find it. Me, I had just finished my lunch-- carry-out chicken from down the street. I even still had the carry-out box in my hand. It was too good of an opportunity to pass up.
I laid out some scratch paper on the user's desk. Then I took my box of chicken bones, and shook them over the computer, muttering "Foo mane padme hum". Then I dumped the chicken bones onto the paper, and studied them for a moment.
"Now the problem may be seen," I pronounced. I rebooted the computer, and subtly held down the left shift key. Some techs may remember, among other things, this would cause the on-disk config.sys to be ignored, and a default loaded-- one that lets himem.sys test the memory.
Sure enough, it reported the failure.
A different company. I was working the phone lines for tech support. The only other guy on support-- a buddy of mine from way back who happened to get hired there-- was green as can be; the company didn't even bother to train him on our product.
He comes to my desk in a hurry. He had a customer who couldn't install our product. He hurredly described the symptoms. I told him to instruct the customer thusly: take the disk, and hold it vertically. As if the disk were a knife, and you were trying to cut the desk, rap the disk against the desk three times. Then try the install again.
The poor fella looked like I had gone insane. "The customer's on the line right now," he said. "This is no time for jokes; I need a real answer!" I refused to tell him any more until he told the customer what I said. He went back to his desk. I could hear him start talking to the customer: "I'm real sorry, but..."
When he came back a few minutes later, his eyes were as wide as saucers. It had worked, the customer was happy. What was all that about?
I explained that there was a bit of dust on the disk surface.
I've done exactly that. Broken computer. I was called to investigate. The low-level techs on the scene briefed me, and said that a cold boot had no effect.
I told them exactly what Knight (according to the koan) had said, word-for-word. Then I power-cycled the box and held my breath.
It worked. I smiled, bowed, and walked away.
Of course the low-level techs asked with incredulity why it started working. (They saw the whole thing.) I refused to elaborate, mostly because I had no clue myself.
I've worked for companies with a different moisture-related problem. Every time the fella would flush his toilet, the servers would reboot.
Cold-water pipe ground, and a loose pipe.
I prefer ex-military people.
When I was in tech support, I loved working with military customers. You tell them, "Do this. Now do that and read me the response." They do this, then that, and read you the response. They don't question your judgement or instructions, and are always very courteous. Many will ask questions if they need additional information or something, but they do what the tech requests.
Usually.
I had a call from one net admin who, while clearly quite knowledgable about Unix (our product) and TCP/IP, was having problems getting a particular BIND setup working. We worked through the problem, and he did everything I asked, and we quickly resolved the problem to a misconfigured slave server that had become lost.
But after we solved that, a "dig" from my end showed very different IPs on that domain's servers than the ones he had read me. I said, "Something's still wrong, I'm seeing such-and-such IP." He sheepishly admitted that the IPs I were seeing were the genuine ones, and the ones he was telling me were bogus. I was quite surprised he had kept up the charade, reading me configs and swapping the bogus IPs for the real ones without hesitation or delay.
My boss had somebody try to pull the same stunt with him once, but much more obviously. "What's the IP," he asked. "Let's say it's..." began the customer. "No, none of this make-believe, I really need your IP." (Our product adhered to a CIDR requirement that the subnet part of an address not be all zeros or all ones, so the actual IPs are really significant.)
But by and large, military are my favorite people to support.
My call with Logitech:
I worked for a mom-and-pop computer store. Got in a new design of joystick. We were going to put it on a display computer, so I open the box, and the unit is broken. The stick lolls over to the side. One of the springs that holds it upright had failed. (Insert juvenile jokes here.)
I call Logitech. The tech asked me, "Did you try it on another computer?" I patiently explained that the problem was mechanical, and was clearly not a computer issue.
"Well, try it on a different computer." I explained the problem again, careful to be clear and precise.
"Alright, then, try it on a different computer." I clarified that the joystick had never been plugged into any computer. Ever (at least not since it entered the shop). I was completely aware of the defect from the moment I removed the joystick from the box. It had never been attached to any computer.
"Are you refusing to try a different computer?"
Everything after that is a blur.
I might not throw that out immediately. The support tech clearly didn't know anything about SCSI vs IDE, but I wouldn't be surprised if he had heard an explaination from someone who did.
Harmonics are a wave phenomenon. Many wave pheonmena-- particularly signal reflection-- are problematic in HDD transmission lines. SCSI has traditionally been more careful about controlling wave artifacts than IDE has, and so was able to get higher bitrates than IDE and its precursors for most of their respective lives. On file servers, bitrates are a big deal.
So there may be a nugget of truth in the tech's response, possibly passed down from a SCSI guru to a random guy to your tech, and lost its meaning a long time ago.
I'm not saying it's for sure, just saying there's potential there.
I thought about this for a moment, and realized I live in area code 408. Bummer. Come to think of it, Silicon Valley just can't use this: our A/Cs are 408, 650, and 415.
Cool idea, though.
I'll see what I can do.
Dear Austrailia,
Please do not take any action that would result in DMCA-type laws being passed in Austrailia. I've always felt that I can move to Austrailia if things get too bad to stay here in America. I'd hate to see things get bad there too.
Kindest regards,
Piquan
The big problem I see in spamland today isn't the classification technology. It's the word recognition problem. Sure, "VIAGRA" may be deeply embedded in a "spam" cluster, but what about "V1_4G ra"? If spammers weren't disguising their words, I think that Bayesian filtering and other techniques work fine. I'm not really sure that more advanced techniques in word classification are really needed here.
Or is it? Wouldn't it be advantageous to the FBI, et al, to release redacted documents without anyone knowing just how much was redacted?
In some circumstances, perhaps. Moreso, it would be advantageous to the FBI to never release anything. But in an open society, that is contrary to the public interest. The needs need to be balanced.
This idea needs refinement. You don't want five pages of text being the same length as a single sentence, because it's important for the public to know how much of the document is being withheld.
I never understood this behaviour anyway. Why show a person on TV that obvoiously not want to be recoznized (however carefully concealed by the production)?
Thursday I saw a documentary about two guys fighting over a baseball. One of them often went to court and made other public appearances with his grilf. The grilf, at the last minute, decided that she didn't want to be shown in the documentary. But she was in all the footage, so they pixelled her out.
Nobody cared about her face. We care about everything else in the film. Extend this concept.
USERNAME+%2@yourdomain.com USERNAME
You don't need this rule. Sendmail defaults to routing foo+bar to foo, unless there's a rule specifically to handle foo+bar.
MEMORANDUM
From: Information Services
To: All personell
Re: Secure computing practices
The following, found during a routine review of our authentication system, are insecure and should never be used:
Avoid anything on this list. Any personell using anything on this list will be required to attend a mandatory fnord security training class, and may possibly face reprimands for repeat offenses.
Actually, given the topic in question, I think he was right.
Okay, last time: 5 is May. I think you meant this to be on 4/1.
Everyone says you can't prove a negative.
And it's not entirely accurate. For example, I might assert that there's a computer disk with a program on it that solves the halting problem. You can prove that it doesn't exist through pure mathematics.
The idea that "you can't prove a negative" generally comes from the concept of a null hypothesis in statistics. Suppose that I want to demonstrate that caffiene affects you metabolism. My null hypothesis is the opposite: that the metabolism of persons who ingest caffiene is the same as persons who don't. My null hypothesis is one which states that a difference does not exist.
Now, I test a bunch of people: my control group doesn't injest caffiene, and my test group does. I then measure their metabolisms. I observe that the test group has heightened cardiovascular activity. So my null hypothesis has been rejected, thus the alternative hypothesis-- that there is an effect-- is justified.
Had I not seen any effect, then the null hypothesis would not have been proven. We merely would have failed to reject it. Perhaps there is an effect that we did not measure, for instance.
I read an article somewhere about faxing carbon paper (all black) continuously by taping 2 sheets of it together in a loop so it would go on and on and waste all their ink.
I'd recommend against carbon paper, since the carbon dust might get on the lens, in the gears, etc and pretty much waste your fax machine. But other things might work well. For an example, take some of his spam and print it out in white-on-black. Be sure to use a callout box for the bit that says effectively "You asked for this!"
(Brushfires to US readers.. though I agree with a slashdot poster of a few months back, who thought that brushfire sounded like a problem caused by overactive grooming...).
And what do you think 'bushfires' sounds like to us yanks?
I don't really keep up with the game world. Can you explain why you feel that Sony is even more evil than Microsoft?
There's many ways to do that-- google for "chaffing and winnowing". Briefly, you chunk the data, stick a MAC at the end of each chunk, and use a different MAC key for each thing you want as a possibility.
These schemes they tend to be obvious from the message length, and the algorithms are almost always designed to support it. When the NSA tech sees you're using a chaffing and winnowing (or similar) algorithm, it's a good guess that you've got another message.
Related, we have steg, which hides messages in other messages. But your outer message needs to be of a sort that has a lot of nearly-redundant data so some can be changed for the hidden message. For example, a soldier deployed to Tunis signed his letters with a different middle initial to tell his family where he was, and still get past the censors. (The letters arrived out of order, and his family wondered where "Nutsi" was.) Modern-day steg typically does things like flip low-order bits of photos, but is often detectable.
If your user account is compromised, you can be tricked into running a different program than you intend.
If my user account is compromised, then I don't really need to be tricked; the attacker can just run the programs directly. Or if he's trying to spoof a password prompt, he can edit my .profile and set my PATH to whatever he wants anyway.
Alternately, if you mess up the permissions on your ~, you can be made to run a different program, compromising the account.
Again, if ~ has bad perms, then the attacker can edit my .profile, so again it's irrelevant what I set my PATH to.
If you disable it in your X config, apps can intercept it, so it's foolish to assume that you're looking at a genuine X/K/GDM after hitting it.
Uh... If the X config has been edited, then that means that root was already compromised. Besides, you can see the monitor mode switch if you hit a C-A-BS and it takes effect.
Except it doesn't log out. It just kills everything very nastily.
Not too nastily. Less nastily than a kill -9, for sure. The apps still can do whatever shutdown operations they need to.
But let me paint you a picture. A lab where most of the occupants aren't Unix people. Some of them aren't really computer people. They're hardware designers, or embedded systems programmers, or {domain} experts, or other such things. All of them are good at what they're hired for, but may not be good at other stuff. Like using a PC.
Most of these people got their .profile and .xsession by copying somebody else's, if they're not just using the system default. They didn't pick their WM, because they don't really care much about their WM. They've never taken time to learn anything. They have their xterm start up when they log in, and a row of CDE-style buttons to launch other xterms, a web browser, and maybe Citrix. No easy button to log out.
So they'll often log into a box, do what they need, then wander over to some piece of equipment they need to work on, without logging out. There's only six general-purpose PCs in the lab, so it doesn't take long before they run out if people stay logged in when they're not using them There's a new threat: people hitting the Reset switch when they come across a logged-in but unoccupied machine.
Now, the lab manager needs to make a notice to log out. If there aren't concise, clear instructions on lab notices, they don't get followed. So that's the notice.
Now the other end. What's the harm? Apps still get their notice to shut down. They can save user configs, send termination notices to network peers, whatever they need to do as long as it doesn't involve interaction with the X server.
Sure, it'd be nice if everybody knew all about the tools they used. Hell, it'd be nice if they had basic understanding of their WMs. But they don't, and we don't expect most of them to any more than we expect them to play a trumpet. It's just not what they need to do for their job.
If the parent had read the link,
I'm assuming you're referring to the UNCG link, which is clearly discussing university policy. The university falls under both the federal and state government agency rules. (Federal because it's receiving US DofEd funding, and state because it's UNC, for pete's sake.) Note that the bit of law they quote at the bottom only applies to government agencies.
And, if your landlord doesn't want to do business with you because you won't give your social, get 'em prosecuted for it. The link clearly states giving up a social security number must be voluntary.
Which link are you talking about? The first one is only discussing University policy, and the second says almost the opposite. While technically it's voluntary, a private business doesn't have to do business if you don't give 'em your SSN. Read the other link, the one from the Social Security Administration:
Perhaps a HUD apartment couldn't ask for your SSN, but I know of no reason a random landlord couldn't.
And as Detritus pointed out, some entities-- such as employers, banks, and others-- may legitimately require your SSN before they're legally allowed to do business with you. For example, employers and banks need your SSN to file reports with the IRS.