RMX, a new DNS record type which lists authorized senders for a particular domain, would have a huge impact in blocking mail with a spoofed sender address. Of course, then spammers could still register their own domains to send from, but those could also be easily blocked, and it would be easier to find the spammers who registered the domain.
I think this has a lot of potential, unlike the other bazillion idiotic non-solutions that have been proposed, like X-mulct headers, for example.
When NASA was preparing for the Apollo Project, it took the astronauts
to a Navajo reservation in Arizona for training. One day, a Navajo elder and his son came across the space crew walking among the rocks.
The elder, who spoke only Navajo, asked a question.
His son translated for the NASA people: "What are these guys in the big
suits doing?"
One of the astronauts said that they were practicing for a trip to the moon. When his son relayed this comment the Navajo elder got all excited and asked if it would be possible to give to the astronauts a message to
deliver to the moon.
Recognizing a promotional opportunity when he saw one, a NASA official
accompanying the astronauts said, "Why certainly!" and told an underling
to get a tape recorder. The Navajo elder's comments into the microphone were brief. The NASA official asked the son if he would translate what his father had said. The son listened to the recording and laughed uproariously. But he refused to translate.
So the NASA people took the tape to a nearby Navajo village and played
it for other members of the tribe. They too laughed long and loudly but
also refused to translate the elder's message to the moon. Finally, an official government translator was summoned. After he finally stopped laughing the translator relayed the message: "Watch out for these assholes. They have come to steal your land."
Oh, of COURSE. Any RESPONSIBLE admin running a large mail system would refuse any existing MTA software and write his own experimental system. Because there JUST MIGHT still be a spammer out there that doesn't use open relays. Big, hairy, fucking troll.
In particular, I direct you to section 4.4 which supports the use of final delivery as a means to stop abusive bounces if you insist on running a dumb relay.
WTF? Section 4.4 specifies behavior regarding trace headers, and says nothing about relaying behavior, or error propagation except for info about the return-path header and how to make sure it allows gatewaying into other systems such as NNTP. All of which is designed to make sure bounces are successfully returned to the sender if the mail is undeliverable.
Here's the scenario if you're using a smart relay: after receiving all the data for a message and before you send a 250 OK, you do the relay service, which fails with a 550, which you can then return instead of a 250. Pretty simple, I think. Sorry you're too simple to see it.
Most MTA software doesn't do what you just described. Systems following SMTP RFCs do not propagate 550 errors. You're talking about an SMTP proxy, not a relay MTA. Proxys are not described in RFC 2821. And they never rewrite the return path, as you suggested in an earlier message. They also do nothing to prevent bounces, since most spammers use an open relay to send their mail, or a cracked Windows box which they have configured to act as an open relay. If the stupid proxy returns a 550, the open relay or cracked Windows box will generate a bounce message anyway.
I'll say it again, since we've already gone over this and you didn't get it last time. EVEN IF MY RELAY RETURNS A 550, THE SPAMMER'S RELAY WILL GENERATE A BOUNCE TO THE REVERSE-PATH. Maybe you can talk the spammers into using proxy servers (though it would dramatically slow down their spam-blast software), or better yet using a null address for the reverse-path. I don't think you'll have much luck, but your energies would be better spent focused in the direction of the spammers who are causing the problem, not mail administrators who are already doing everything they can with the tools they have available.
I see you have marked me as a Slashdot "foe". Seems like an ungrateful thing to do to someone who has spent so much time educating you about how e-mail works in the real world. You obviously have never been responsible for running a large mail system.
This will be my last post, since I've made a number of key points multiple times, it's obvious you're not getting it, and I just don't have any more time to waste explaining why your scheme is both completely ineffective and does not accurately describe the behavior of MTA software. I originally quoted 821 because most of it is copied word-for-word into 2821, and it has a shorter, less complex explanation for many things that still accurately reflect the behavior of real mail systems today.
Get some experience with real MTA software and take a look at how it ACTUALLY works before you go spouting off about how you THINK it should work based on your misunderstanding of the RFCs.
While certainly generous, the Cougaar license is designed specifically to prevent anyone from profiting from the sale of the software
I disagree, people can profit from it the same way they profit from other OSS projects. Without looking at it in depth, it seems to me a clone of the Mozilla Public License. Not Free in the GNU/Richard Stallman sense, but it does appear to meet the Open Source definition. If not, I'm sure ESR would be interested since they use the Open Source trademark.
All I know is that 2821 allows for exactly what I say, interpreting your dumb relay as a point of final delivery.
Wow, it's all you know, and it's wrong. How tragic. Have another hit on the crack-pipe, Doc. May it ease your pain. 2821 still requires bouncing, by the way. See section 3.7, which is almost word-for-word what I quoted in my earlier message from 821. The biggest difference is that it capitalizes the word MUST, emphasizing my point.
Wow, you just don't get it, do you? If everyone followed my suggestion there wouldn't be dumb servers in this day and age and 550 errors would propagate freely and everyone who is supposed to would get them.
Hee hee, you crack me up. Where did you get the idea that 550 errors propagate?
Yes, that would mean you don't bounce things because the system downstream has a problem. Make them be the ones that have to deal with their own delivery problems.
That's not how it works. If the user doesn't exist, the downstream server (which I don't necessarily have control over) returns a permanent failure (550), in which case my relay won't be able to deliver the message.
This is from section 3.6 of RFC 821:
If a server-SMTP has accepted the task of relaying the mail and later finds that the forward-path is incorrect or that the mail cannot be delivered for whatever reason, then it must construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path).
So, tell me again how bounces are not required? Note use of the word "must" in that sentence. Also note that the bounce must be sent to the originator "as indicated by the reverse-path". The reverse-path is defined as the envelope sender, the addressed specified in the MAIL FROM command, in case you were wondering. Rewriting the reverse-path to either null or the downstream postmaster, as you suggest, is clearly a violation of the RFC. If everyone followed your suggestion, every time someone made a typo in a mail address, they would never be notified that their message wasn't delivered. That's the very definition of lost mail. You said in your original message that bouncing spam with a bad forward- and reverse-path "loses mail", which I still don't get, since the sender intended for it to be lost by not giving a correct from address. But you don't seem to be concerned about the behavior of non-spam, legitimate mail. Maybe I have wasted way too much time feeding a troll. My congratulations, you sounded pretty sincere. A masterful performance. Bye now.
Here's my retort: you're an incompetent admin if you can't manage (or manage to set up) a mail network without sending abusive bounces.
Or maybe you have a software package which can determine spam vs. non-spam with none, zero, NEVER hitting a false positive, and you are confident enough in its security that you're willing to install it on your mail relay. Of course, such a program is demonstrably impossible; one person's spam is another persons vital marketing data/subscribed mailing list/penis growth miracle.
But just for the sake of demonstrating your incredible skillz as an e-mail super-guru, let's say you had this all worked out, and you silently discard all spam that your software identifies with no bounces. Congratulations! You have eliminated.000005% of the joe-job problem! You now have only to get your magical software installed on every other mail server in the world, and convince all us incompetent admins that it will never, ever, silently discard a real message. Good luck, I hope your campaign is successful. But maybe you should get some practice explaining your idea, because I'm still just guessing as to what the hell you are talking about.
Uh, what part of "accept all recipients" didn't you understand? If you're so foolish as to set up a dumb server, you damn well better make it dumb; so dumb it does nothing but pass things inward. To do otherwise makes you a source of abuse.
Are you suggesting we never bounce any messages, including legitimate mail that has a typo in the username, or mail accounts that are no longer valid? You know, admins of legitimate mailing lists find those bounces very useful. I occasionally find bounces useful in diagnosing problems myself. People generally like to be notified if they make a typo in the address when they are sending a time-critical message. Not to mention that bounces are required by RFCs. Besides, even if we did set up the servers to blindly accept ALL mail to our domain and silently discard errors, there's nothing stopping users from using mailwasher, procmail, etc. and bouncing their spam themselves. You're calling me an incompetent admin? Yeah, that carries a lot of weight coming from you. You were right, I didn't understand what you were suggesting at first; I was giving you too much credit.
I will agree that relays are a tricky issue. I also think that relaying is a dated issue. There is really no reason to have a dumb relay anymore. If I can get web hosting for $5/month, it should certainly be possible to anyone who needs to accept email for a domain to have a mail server always available to accept messages directly.
OK, I'll take the time to spell it out for you.
1) If you're running a domain with more than 1000 valid addresses it often makes sense to have multiple delivery hosts with an smtp hub routing mail
2) For security reasons, you don't want that central hub Internet accessible. If you're attacked, you want the organization's internal e-mail to continue functioning. I'm not talking about ISPs, I'm talking about organizations where e-mail is an essential communications medium.
3) a dumb relay is the simplest, most secure, nearly maintenance free method of getting that mail inside your protected network.
Alternatively, as a server accepting messages for relaying, you should require the downstream to accept all recipients. You have failed to make a case for bouncing either way.
If the downstream gives a 550 error upon relaying, the relay host bounces the message anyway. Your "solution" doesn't work.
I do not think "lose a message" means what you think it means.
Then what does it mean? The message doesn't get to the recipient, and the person who actually sent it gets no error or notification of failure. Sounds lost to me. Please show how I am mistaken.
Your problem is that the person who spoofed the reply-to is the one who lost it. If they don't put the correct info in the message, the RFCs don't require the mail servers to mysteriously determine the ACTUAL sender despite that senders attempts at anonymity. The MAIL SERVER doesn't lose the mail, the message was lost before it was ever sent if both sender and recipient headers are invalid. If you violate the RFCs when composing the message, you can't expect to hold the downstream servers accountable for "lost mail" which never had a valid sender OR recipient. It's not lost - it was never found. It's dead, gone to meet its maker. It's an EX-MESSAGE.:-)
Read the damm article. It wasn't a couple thousand, it was nearly a million across the three domains - and they got off lightly.
I'm not saying joe-jobbing doesn't suck.
All I'm saying is that setting up every MX host to know all valid mail addresses in its domain is stupid and impractical.
If you control an MX, please configure it to issue a 550 error during the connection if you can't deliver the message
Many Internet-accessible MX hosts are not also running delivery services (POP, IMAP, etc.) They often relay the mail to a non-internet-accessible SMTP hub for the domain, which in turn relays the mail to the hosts running the delivery agents. There's usually no way the Internet MX host can know which users are valid.
Don't try to pass this off on mail admins. We're doing what we can, spending way more time setting up ways to filter out this crap than we should have to. Direct your bile at the spammers.
which means you anal types who say "RFC says I must bounce" have to note that it also says you must not lose a message, which is what a bad bounce does.
I do not think "lose a message" means what you think it means. I like the RFCs. I just don't think your little suggestion does much good except for the poor joe-jobbee. I've been joe-jobbed. Yeah, it sucked. But I'd rather delete a couple thousand messages once in a blue moon than ask every admin on the Internet to set up their mail servers so that the spammers can more easily validate their address lists.
Matt Groening says he was only joking about Fox News suing the Simpsons.
So it was a story that was completely made up by one person, and all the lefty blogs were up in arms over it.
Where are the slashdotters complaining that Fox News was thin-skinned, censoring or plain evil now? Hopefully you would think they'd be man enough to apologize and admit they were wrong.
Well, like most Simpsons jokes, just because Mr. Groening was joking doesn't mean his point wasn't right on target.
Fox IS thin-skinned. They have used the legal system in an attempt to silence their critics at least TWICE in the past year. Both times, the judge shut down the suits for their meritlessness.
They
sued political satirist Al Franken.
They sued AgitProperties, the makers of Faux News T-shirts.
You would think a news organization would know better than to try to use the legal system to shut up their critics. In both cases, they only managed to generate PR for the people they sued and boost the sales of Mr. Franken's book and the Faux News T-shirts. I don't care for Franken's style, myself. I don't think he's funny or even interesting. But I did buy a Faux News T-shirt the day I heard about the lawsuit.
Since query results are.Net objects, maybe we can build a GNU shell like this based on Mono. Lessee, what to call it... MONAD... GNU... GONAD!
GONAD will be pure innovation. What's that you say? Linux has had a powerful programmable shell with consistent behavior for over ten years? Oh MAN, I thought we had something NEW here.
Due to a fight on Capitol Hill, NOAA's Space Environment Center (which tracks these events and other 'space weather' items) will not have any funding in 2004. The part of Congress that oversees NOAA does not think NOAA should have to pay for this, and has decided to cancel its funding in hopes that they can force NASA or the Air Force to pick up the tab.
Actually, the Space Environment Center knew its funding was on the line, which is why they sent an antimatter containment pod into the sun last week, triggering these flares, hoping to cause a massive power crisis and ensure their funding. Not that you'll hear about this in the Liberal Media. And don't forget to wear your tinfoil.
traffic jams -> scarcity of alternative transportation
Actually, it's neither abundance of cars or scarcity of alternative transportation. It's an abundant scarcity of abundance of scarcities. Now, THIS is news.
ps2pdf is a little shell script which calls ghostscript to convert postscript to pdf. You can also set up an lpd server to use ghostscript as a print filter. I wrote a simple little CGI script to make the generated PDFs available via apache so users didn't need access to the box - they just print to the PDF spool and then download their pdf from the web page. Jobs are deleted after 3 days via cron. 'Course I set all this up before CUPS was available... there's probably an easier way to do this with CUPS-PDF.
Now contrast this with an open source business model:
1. Modify an open source software package to fit a niche market
2. Sell installations, manuals, customization service, and support to that market
3. Profit!
Unfortunately I haven't seen many Open Source businesses manage to achieve point 3.
I'm sure everyone can mention a few that have done so (Redhat and Cygwin spring to mind) but there are vastly more that have either fallen by the wayside or are resorting to begging for money (Mandrake?).
Wrong business model. Note the word "niche" -- this model is for smaller companies that aren't covered by Slashdot all the time. But there are a lot of them out there. And even when they do make the news, they don't necessarily want to advertise that they're using F/OS software as part of their product.
Redhat, Cygwin, and Mandrake have much larger target markets, the software they produce is more general-purpose. Different business model. They are trying to make a little money from each of a LOT of customers, while the niche market guys try to make a lot of money from each of a FEW customers.
Advanced developers will appreciate it however, especially with Ingo's lead-in warning that 100% of the material in the chapter is undocumented by Microsoft!
Whaaaaaa? A Microsoft API with incomplete documentation?
Yes, the terrorism statement was idiotic, but there's more to the article than just that.
The author mentions that unprofessional people hold onto their beliefs regardless of the facts. Then he says that he believes SCO will win the lawsuit because he thinks the "priests and zealots" are bending the truth.
With regard to SCO, the facts are that we have no facts. We have a big steaming pile of hyperbole and half-truths from SCO press releases. We have assurances from SGI and IBM that they do actually own all the code they contributed. But we have no facts.
Several people known for their extremely professional attitudes (Linus, for one), and who are familiar with the code that SGI and IBM have contributed have stated that they do not believe any of the contributed code could have derived from code for which SCO has the right to restrict copying and distribution.
We also know that SCO has not been making money from their products and services lately, and before the lawsuit were in desperate straights. They have motivation to lie.
Given all this, I would have to say that the author of the article is himself ignoring the facts.
If I were building a theme park, I'd care more about engineers giving me the thumbs up than the kids.
And if I were building a theme park, I'd want thumbs-up from both.
Absolutely. But the point was, which one is more important? I think I'd have to go with the engineers. Are you familiar with secondary MX hosts? It's a backup feature. It only gets used when your main mail server gets hosed, or the DNS for your main mail server gets hosed. That feature was broken by Verisign's "innovation". The users don't care about that, because they didn't even know they HAD a backup mail server. Just like the kids at the theme park don't care about the mathematics of roller coaster load distribution. Nobody cares about it but the engineers, until something breaks.
Linux is a kernel, and not an operating system, knowing that is _your_ duty. Nobody has the right to be ignorant.
On the contrary, everyone has the right to be ignorant. You can try to educate people, tell them Linux is just the kernel, but they don't have to listen to you. What are you going to do about it? Nothing.
Dumbass Bill of Rights: 1) Everyone has the right to be ignorant 2) Everyone has the right to get upset about other people's ignorance 3) Everyone has the right to laugh at all the people exercising the first two rights.
Slashdot Mirror
RMX, a new DNS record type which lists authorized senders for a particular domain, would have a huge impact in blocking mail with a spoofed sender address. Of course, then spammers could still register their own domains to send from, but those could also be easily blocked, and it would be easier to find the spammers who registered the domain.
I think this has a lot of potential, unlike the other bazillion idiotic non-solutions that have been proposed, like X-mulct headers, for example.
"The people who develop open-source code," Perens said, "are getting tired of being told that they have to pay to use it."
When NASA was preparing for the Apollo Project, it took the astronauts to a Navajo reservation in Arizona for training. One day, a Navajo elder and his son came across the space crew walking among the rocks.
The elder, who spoke only Navajo, asked a question. His son translated for the NASA people: "What are these guys in the big suits doing?"
One of the astronauts said that they were practicing for a trip to the moon. When his son relayed this comment the Navajo elder got all excited and asked if it would be possible to give to the astronauts a message to deliver to the moon.
Recognizing a promotional opportunity when he saw one, a NASA official accompanying the astronauts said, "Why certainly!" and told an underling to get a tape recorder. The Navajo elder's comments into the microphone were brief. The NASA official asked the son if he would translate what his father had said. The son listened to the recording and laughed uproariously. But he refused to translate.
So the NASA people took the tape to a nearby Navajo village and played it for other members of the tribe. They too laughed long and loudly but also refused to translate the elder's message to the moon. Finally, an official government translator was summoned. After he finally stopped laughing the translator relayed the message: "Watch out for these assholes. They have come to steal your land."
Oh, of COURSE. Any RESPONSIBLE admin running a large mail system would refuse any existing MTA software and write his own experimental system. Because there JUST MIGHT still be a spammer out there that doesn't use open relays. Big, hairy, fucking troll.
In particular, I direct you to section 4.4 which supports the use of final delivery as a means to stop abusive bounces if you insist on running a dumb relay.
WTF? Section 4.4 specifies behavior regarding trace headers, and says nothing about relaying behavior, or error propagation except for info about the return-path header and how to make sure it allows gatewaying into other systems such as NNTP. All of which is designed to make sure bounces are successfully returned to the sender if the mail is undeliverable.
Here's the scenario if you're using a smart relay: after receiving all the data for a message and before you send a 250 OK, you do the relay service, which fails with a 550, which you can then return instead of a 250. Pretty simple, I think. Sorry you're too simple to see it.
Most MTA software doesn't do what you just described. Systems following SMTP RFCs do not propagate 550 errors. You're talking about an SMTP proxy, not a relay MTA. Proxys are not described in RFC 2821. And they never rewrite the return path, as you suggested in an earlier message. They also do nothing to prevent bounces, since most spammers use an open relay to send their mail, or a cracked Windows box which they have configured to act as an open relay. If the stupid proxy returns a 550, the open relay or cracked Windows box will generate a bounce message anyway.
I'll say it again, since we've already gone over this and you didn't get it last time. EVEN IF MY RELAY RETURNS A 550, THE SPAMMER'S RELAY WILL GENERATE A BOUNCE TO THE REVERSE-PATH. Maybe you can talk the spammers into using proxy servers (though it would dramatically slow down their spam-blast software), or better yet using a null address for the reverse-path. I don't think you'll have much luck, but your energies would be better spent focused in the direction of the spammers who are causing the problem, not mail administrators who are already doing everything they can with the tools they have available.
I see you have marked me as a Slashdot "foe". Seems like an ungrateful thing to do to someone who has spent so much time educating you about how e-mail works in the real world. You obviously have never been responsible for running a large mail system.
This will be my last post, since I've made a number of key points multiple times, it's obvious you're not getting it, and I just don't have any more time to waste explaining why your scheme is both completely ineffective and does not accurately describe the behavior of MTA software. I originally quoted 821 because most of it is copied word-for-word into 2821, and it has a shorter, less complex explanation for many things that still accurately reflect the behavior of real mail systems today.
Get some experience with real MTA software and take a look at how it ACTUALLY works before you go spouting off about how you THINK it should work based on your misunderstanding of the RFCs.
While certainly generous, the Cougaar license is designed specifically to prevent anyone from profiting from the sale of the software
I disagree, people can profit from it the same way they profit from other OSS projects. Without looking at it in depth, it seems to me a clone of the Mozilla Public License. Not Free in the GNU/Richard Stallman sense, but it does appear to meet the Open Source definition. If not, I'm sure ESR would be interested since they use the Open Source trademark.
All I know is that 2821 allows for exactly what I say, interpreting your dumb relay as a point of final delivery.
Wow, it's all you know, and it's wrong. How tragic. Have another hit on the crack-pipe, Doc. May it ease your pain. 2821 still requires bouncing, by the way. See section 3.7, which is almost word-for-word what I quoted in my earlier message from 821. The biggest difference is that it capitalizes the word MUST, emphasizing my point.
Wow, you just don't get it, do you? If everyone followed my suggestion there wouldn't be dumb servers in this day and age and 550 errors would propagate freely and everyone who is supposed to would get them.
Hee hee, you crack me up. Where did you get the idea that 550 errors propagate?
That's not how it works. If the user doesn't exist, the downstream server (which I don't necessarily have control over) returns a permanent failure (550), in which case my relay won't be able to deliver the message. This is from section 3.6 of RFC 821: So, tell me again how bounces are not required? Note use of the word "must" in that sentence. Also note that the bounce must be sent to the originator "as indicated by the reverse-path". The reverse-path is defined as the envelope sender, the addressed specified in the MAIL FROM command, in case you were wondering. Rewriting the reverse-path to either null or the downstream postmaster, as you suggest, is clearly a violation of the RFC. If everyone followed your suggestion, every time someone made a typo in a mail address, they would never be notified that their message wasn't delivered. That's the very definition of lost mail. You said in your original message that bouncing spam with a bad forward- and reverse-path "loses mail", which I still don't get, since the sender intended for it to be lost by not giving a correct from address. But you don't seem to be concerned about the behavior of non-spam, legitimate mail. Maybe I have wasted way too much time feeding a troll. My congratulations, you sounded pretty sincere. A masterful performance. Bye now.
Here's my retort: you're an incompetent admin if you can't manage (or manage to set up) a mail network without sending abusive bounces.
.000005% of the joe-job problem! You now have only to get your magical software installed on every other mail server in the world, and convince all us incompetent admins that it will never, ever, silently discard a real message. Good luck, I hope your campaign is successful. But maybe you should get some practice explaining your idea, because I'm still just guessing as to what the hell you are talking about.
Or maybe you have a software package which can determine spam vs. non-spam with none, zero, NEVER hitting a false positive, and you are confident enough in its security that you're willing to install it on your mail relay. Of course, such a program is demonstrably impossible; one person's spam is another persons vital marketing data/subscribed mailing list/penis growth miracle.
But just for the sake of demonstrating your incredible skillz as an e-mail super-guru, let's say you had this all worked out, and you silently discard all spam that your software identifies with no bounces. Congratulations! You have eliminated
Uh, what part of "accept all recipients" didn't you understand? If you're so foolish as to set up a dumb server, you damn well better make it dumb; so dumb it does nothing but pass things inward. To do otherwise makes you a source of abuse.
Are you suggesting we never bounce any messages, including legitimate mail that has a typo in the username, or mail accounts that are no longer valid? You know, admins of legitimate mailing lists find those bounces very useful. I occasionally find bounces useful in diagnosing problems myself. People generally like to be notified if they make a typo in the address when they are sending a time-critical message. Not to mention that bounces are required by RFCs. Besides, even if we did set up the servers to blindly accept ALL mail to our domain and silently discard errors, there's nothing stopping users from using mailwasher, procmail, etc. and bouncing their spam themselves. You're calling me an incompetent admin? Yeah, that carries a lot of weight coming from you. You were right, I didn't understand what you were suggesting at first; I was giving you too much credit.
OK, I'll take the time to spell it out for you.
1) If you're running a domain with more than 1000 valid addresses it often makes sense to have multiple delivery hosts with an smtp hub routing mail
2) For security reasons, you don't want that central hub Internet accessible. If you're attacked, you want the organization's internal e-mail to continue functioning. I'm not talking about ISPs, I'm talking about organizations where e-mail is an essential communications medium.
3) a dumb relay is the simplest, most secure, nearly maintenance free method of getting that mail inside your protected network.
Alternatively, as a server accepting messages for relaying, you should require the downstream to accept all recipients. You have failed to make a case for bouncing either way.
If the downstream gives a 550 error upon relaying, the relay host bounces the message anyway. Your "solution" doesn't work. Then what does it mean? The message doesn't get to the recipient, and the person who actually sent it gets no error or notification of failure. Sounds lost to me. Please show how I am mistaken.
Your problem is that the person who spoofed the reply-to is the one who lost it. If they don't put the correct info in the message, the RFCs don't require the mail servers to mysteriously determine the ACTUAL sender despite that senders attempts at anonymity. The MAIL SERVER doesn't lose the mail, the message was lost before it was ever sent if both sender and recipient headers are invalid. If you violate the RFCs when composing the message, you can't expect to hold the downstream servers accountable for "lost mail" which never had a valid sender OR recipient. It's not lost - it was never found. It's dead, gone to meet its maker. It's an EX-MESSAGE.
Read the damm article. It wasn't a couple thousand, it was nearly a million across the three domains - and they got off lightly.
I'm not saying joe-jobbing doesn't suck. All I'm saying is that setting up every MX host to know all valid mail addresses in its domain is stupid and impractical.
If you control an MX, please configure it to issue a 550 error during the connection if you can't deliver the message
Many Internet-accessible MX hosts are not also running delivery services (POP, IMAP, etc.) They often relay the mail to a non-internet-accessible SMTP hub for the domain, which in turn relays the mail to the hosts running the delivery agents. There's usually no way the Internet MX host can know which users are valid.
Don't try to pass this off on mail admins. We're doing what we can, spending way more time setting up ways to filter out this crap than we should have to. Direct your bile at the spammers.
which means you anal types who say "RFC says I must bounce" have to note that it also says you must not lose a message, which is what a bad bounce does.
I do not think "lose a message" means what you think it means. I like the RFCs. I just don't think your little suggestion does much good except for the poor joe-jobbee. I've been joe-jobbed. Yeah, it sucked. But I'd rather delete a couple thousand messages once in a blue moon than ask every admin on the Internet to set up their mail servers so that the spammers can more easily validate their address lists.
You would think a news organization would know better than to try to use the legal system to shut up their critics. In both cases, they only managed to generate PR for the people they sued and boost the sales of Mr. Franken's book and the Faux News T-shirts. I don't care for Franken's style, myself. I don't think he's funny or even interesting. But I did buy a Faux News T-shirt the day I heard about the lawsuit.
And the fact is, Fox IS biased. Take a peek at what Fox News employee Charles Reina had to say last Wednesday about how Fox upper management pushes the conservative agenda in the Fox newsroom.
Big noocleer program you've found over thar too.
That should be "nookular", not "noocleer". "Noocleer" is way too close to the correct pronunciation to be representative of Bush's speech.
Since query results are .Net objects, maybe we can build a GNU shell like this based on Mono. Lessee, what to call it... MONAD... GNU... GONAD!
GONAD will be pure innovation. What's that you say? Linux has had a powerful programmable shell with consistent behavior for over ten years? Oh MAN, I thought we had something NEW here.
Due to a fight on Capitol Hill, NOAA's Space Environment Center (which tracks these events and other 'space weather' items) will not have any funding in 2004. The part of Congress that oversees NOAA does not think NOAA should have to pay for this, and has decided to cancel its funding in hopes that they can force NASA or the Air Force to pick up the tab.
Actually, the Space Environment Center knew its funding was on the line, which is why they sent an antimatter containment pod into the sun last week, triggering these flares, hoping to cause a massive power crisis and ensure their funding. Not that you'll hear about this in the Liberal Media. And don't forget to wear your tinfoil.
traffic jams -> scarcity of alternative transportation
Actually, it's neither abundance of cars or scarcity of alternative transportation. It's an abundant scarcity of abundance of scarcities. Now, THIS is news.
ps2pdf is a little shell script which calls ghostscript to convert postscript to pdf. You can also set up an lpd server to use ghostscript as a print filter. I wrote a simple little CGI script to make the generated PDFs available via apache so users didn't need access to the box - they just print to the PDF spool and then download their pdf from the web page. Jobs are deleted after 3 days via cron. 'Course I set all this up before CUPS was available... there's probably an easier way to do this with CUPS-PDF.
Redhat, Cygwin, and Mandrake have much larger target markets, the software they produce is more general-purpose. Different business model. They are trying to make a little money from each of a LOT of customers, while the niche market guys try to make a lot of money from each of a FEW customers.
I can't believe it!
Say it isn't so!
By the way, the sig I've been using for over a year now applies pretty well to the current discussion. Take note, ye terr^H^H^H^Hzealots. :-)
Yes, the terrorism statement was idiotic, but there's more to the article than just that. The author mentions that unprofessional people hold onto their beliefs regardless of the facts. Then he says that he believes SCO will win the lawsuit because he thinks the "priests and zealots" are bending the truth. With regard to SCO, the facts are that we have no facts. We have a big steaming pile of hyperbole and half-truths from SCO press releases. We have assurances from SGI and IBM that they do actually own all the code they contributed. But we have no facts. Several people known for their extremely professional attitudes (Linus, for one), and who are familiar with the code that SGI and IBM have contributed have stated that they do not believe any of the contributed code could have derived from code for which SCO has the right to restrict copying and distribution. We also know that SCO has not been making money from their products and services lately, and before the lawsuit were in desperate straights. They have motivation to lie. Given all this, I would have to say that the author of the article is himself ignoring the facts.
Absolutely. But the point was, which one is more important? I think I'd have to go with the engineers. Are you familiar with secondary MX hosts? It's a backup feature. It only gets used when your main mail server gets hosed, or the DNS for your main mail server gets hosed. That feature was broken by Verisign's "innovation". The users don't care about that, because they didn't even know they HAD a backup mail server. Just like the kids at the theme park don't care about the mathematics of roller coaster load distribution. Nobody cares about it but the engineers, until something breaks.
Linux is a kernel, and not an operating system, knowing that is _your_ duty. Nobody has the right to be ignorant.
On the contrary, everyone has the right to be ignorant. You can try to educate people, tell them Linux is just the kernel, but they don't have to listen to you. What are you going to do about it? Nothing.
Dumbass Bill of Rights:
1) Everyone has the right to be ignorant
2) Everyone has the right to get upset about other people's ignorance
3) Everyone has the right to laugh at all the people exercising the first two rights.