It is one or the other. It is impossible to increase security without reducing anonimity.
Rubbish. Anonymity comes within a context. If you give all your friends keys to your apartment, that doesn't necessarily tell you which individual was nice enough to drop off your mail and water your plants while you were on vacation. Similarly, if you sent me a key in the mail, you will have extended your web of trust, but completely anonymously; neither you or your friends know who I am seen in your apartment.
For example, there is not yet a possibility to only receive email from people that have revealed their identity with a trusted third party. I am affraid that is mainly a problem of legacy that a secure email protocol has not been deployed yet.
I'd say you're wrong here, too. SPEWS and other blocklists are examples of exactly that kind of trust issues being applied to current mail systems.
If you don't vote, then guess what? You don't get the right to bitch and moan when things don't go the way you want them to, plain and simple.
George Carlin has a hilarious routine that argues just the opposite: those that participate in a system they know to be wrong have no right to complain when it behaves as expected. Only those who do not vote can reasonably say they are not responsible for the misdeeds of those who have been elected to office.
It's fucked up, this political system we have, but at this point in time our only voice is by voting.
If you really believe that is your only voice, you are as powerless as those you vote for want you to be. If you instead believe your cause is just, revolution is possible. That may sound like terrorism to some, but I shouldn't have to point out to anyone on Slashdot that from the perspective of England, the actions in the American Colonies were just that. Or, to quote an American President 40 years dead: "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John Fitzgerald Kennedy
The world is a big place. You ought to get out and see more of it.
This is an odd statement. The truth is that those who actually do get out and see the world are those most exposed to the problems that miscommunication causes. Far too many people tie their culture to their communication and are unwilling to change. If most countries can seem to standardize on the metric system without much problem, why can't they all standardize on a language (any single language; not necessarily English)? If we can all share Euros, why can't we all share the same word for money?
What this reminds me of is how the Feds are made to work in Neal Stephenson's Snow Crash: the first ones in in the morning take the desks nearest the door and management can tell at a glance who's the most dedicated to the job.
Which, of course, is based on the old classroom practice of sitting at the front if you wanted to get teacher's attention. Like you say, though, a company is screwed if their management takes those shortcuts to evaluate who the eager employees are. Sometimes the person coming in early isn't the best employee, but merely the one that has to come in early to put in a day the company considers productive. There were jobs where I was allowed a number of times to skate in just before lunch without punishment simply because I was doing more than enough in the hours that I was there to justify my salary.
And even if I were at a company that evaluated you based on your sitting position, I'd sit in the back. I sat in back in class so that I could take in the whole class; simply having teacher's attention often wasn't enough to keep me interested in the subject, especially if teacher was moving slow for other students on something I already understood. I'd sit in the "back" in a desk pool simply because it would increase my chance of getting the same desk every day, and then all that "no personal items" BS would have less effect on me.
That only shows how timely the definition of a supercomputer is. 100 common desktop machines are very uncommon and obsolete 3 years from now.
Right. I recall Apple making a big stink a few years back about being a desktop supercomputer when they hit 1 GFLOPS, or whatever the benchmark was that initially established the first supercomputers. What makes a computer "super" while Moore's law is still being met will definitely change over time.
I think energy efficiency (MOPS/Watt) is a very relevant metric.
Only inasmuch as electricity costs money, and those costs can be compared to the cost of pushing more horsepower at the problem. I mean, if you have some calculations that daily require a 1 TFLOPS cluster (say some weather prediction), it doesn't much matter if you can get a.5 TFLOPS cluster that consumes 75% less power. Yeah, in theory you could get two, but there are coordination costs and scaling inefficiencies that would have to be dealt with so that in order to actually see 1 TFLOPS from the the second architecture it might end up being less efficient and requiring more energy.
All I'm saying is that if they want to claim any sort of efficient supercomputer, they have to have something on the Top 500 list and then worry/brag about what kind of low power consumption it has.
. . . might there be other metrics that might be important to supercomputing, rather than relying solely on processing speed?
No. I have a rock that can sit and do nothing, consuming considerably less than even 5.2kW. You can talk efficiency and bang-for-buck all you like, but if you don't benchmark faster than (roughly) 100 common desktop machines, you don't get to call yourself a supercomputer.
No single media of any kind is a good way to archive anything. Afterall, that's exactly what got you into trouble in the first place. If you expect the one CD to last 25 years then you've learned nothing from your tape experience. If you only have one copy of something, you have a single point of failure. Anything really important should be encoded in multiple formats written to multiple media and stored in multiple locations.
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.
Do you have ADD or something? There are two discussions going on and you seem unable to focus on one at at time. The first is regarding your dumb relaying server and the second is what a smarter server could do.
All of which is designed to make sure bounces are successfully returned to the sender if the mail is undeliverable.
This has become tiresome. How many times do I have do point out that you are not returning anything to the sender with your crappy bounces. You are misdirecting message to a third party: whoever got forged into the From header. I'm done trying to explain that point to you. Take your medication before reading and responding already!
Most MTA software doesn't do what you just described.
Holy fuck, that's why the thread started in the first place! Most servers are lazy outdated pieces of shit. The were constructed in a time when the Internet was a happy academic playground. My whole complaint is that RFCs allow them to better address attempted abuse.
Systems following SMTP RFCs do not propagate 550 errors.
They are not prevented from doing so, either. Just because you have a "reference" implementation in sendmail (or whatever) that is easy to install doesn't make it the last word on what a server can do. Just admit you're a lazy admin and stop trying to hide behind a manufactured understanding of RFCs.
EVEN IF MY RELAY RETURNS A 550, THE SPAMMER'S RELAY WILL GENERATE A BOUNCE TO THE REVERSE-PATH.
What a shitty excuse. Just because there might be some other crap server in the chain is no reason you can't keep your own house clean. If I get garbage from a server, I can block it; wouldn't you prefer I block the spammer's relay than your server?
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.
Oh, please. Admins are doing far less than is allowed. They're mostly just lazy fucks who install something off the shelf to handle mail without too many hassles.
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.
On the contrary, I have obviously been more responsible in my mail administration than you have. I know "how e-mail works in the real world"; it doesn't work. It's bloody teetering on the brink of destruction. If your not going to take some responsibility in cleaning it up, if you're going to twist RFCs to favor spammers, damn straight you're a foe.
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.
You still fail to get that the whole point is that how things "ACTUALLY work" is broken. How very sad for you and your users.
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.
For future reference, when someone informs you of an updated RFC which you hadn't bothered to read for the last 2 years, read the fucking thing. Not just the section that you think supports your point, but the whole thing including the sections that might be less supportive. 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.
Where did you get the idea that 550 errors propagate?
On your systems they clearly don't, but we've already established you're a spam-friendly asshole. 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.
So, tell me again how bounces are not required? Note use of the word "must" in that sentence.
It doesn't say "you must send the message to an unrelated third party that you know damn well was forged". It just says a notification must be sent following a certain procedure. That procedure allows you to direct that notification inward where it belongs, which I have already noted is the only proper thing for a dumb server to do. Can the RFC be interpreted to allow you to be a jerk? Yes. Does that mean you have to be a jerk? No.
Rewriting the reverse-path to either null or the downstream postmaster, as you suggest, is clearly a violation of the RFC.
Since you're still reading 821, I don't know why I bother with you. All I know is that 2821 allows for exactly what I say, interpreting your dumb relay as a point of final delivery. It is allowed. You don't have do be a prick and bounce the joe-job, so don't do it.
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.
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. Only what you do is "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.
That is likely the quickest psychotic break I've ever seen. In one sentence you're saying the sender is intending a message to be lost and in the next you're talking about that as the legitimate use of mail. It's clear you're trying to see things not from the perspective of a responsible admin, but as a spammer. Way to out yourself, genius.
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?
I'm not suggesting, I'm precisely stating what I want. You want to put up a dumb relay? You had better make it totally stupid. 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.
People generally like to be notified if they make a typo in the address when they are sending a time-critical message.
But your bounces don't do that. They notify the From address. What if there was a typo there, too? The only way you can properly notify the actual sender is a server error.
Not to mention that bounces are required by RFCs
Wrong. Did you not even read my initial message? What your dumb server really should do is set the Return-Path to either null or the postmaster of the system you're relaying to. Again, if you cannot reasonably return a server error on non-delivery, you can not reasonably bounce a message either. A dumb relay should be dumb, and not pretend it is smart enough to do more than shuffle things inward.
You're calling me an incompetent admin?
No, I'm just pointing out that's what you're demonstrating. Stop defending outdated, lazy behavior and fix your systems.
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.
What the hell are you talking about? Detection of spam, or any other non-delivery issues, is a separate issue from the response. A joe-job happens when a server accepts a message it cannot deliver and it then bounces to a forged From header. My initial solution stands: if you do detection before fully accepting the message it allows you to respond with a proper error. I'm not sure why you find that so difficult to see.
Congratulations! You have eliminated.000005% of the joe-job problem!
No, I have eliminated 100% of my abusive messages. If you can't show me the same courtesy, if you continue to send abusive bounces, you might just find yourself unable to connect at all in the future. So stop being an ass and fix your server so we can all deal with the spammers themselves instead of infighting.
Nice and condescending right off the bat. I like that. 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.
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
Irrelevant. I don't care if you have a host for every email and a 20 relay tree to reach them. Manage the setup properly and stop accepting messages such that you bounce improperly.
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.
Also irrelevant. Again, your internal structure does not in any way require you to send abusive bounces.
3) a dumb relay is the simplest, most secure, nearly maintenance free method of getting that mail inside your protected network.
Not true, plus it makes you a real asshole for everyone else on the Internet. Being a lazy fuck who doesn't care is not a bullet point you would want to broadcast. All you get is simple, not secure or reliable. If you disagree, please feel free to "spell it out" further.
If the downstream gives a 550 error upon relaying, the relay host bounces the message anyway. Your "solution" doesn't work.
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.
Your problem is that the person who spoofed the reply-to is the one who lost it.
No, your problem is that you accepted the message for delivery prematurely. Then you found you couldn't actually live up to your responsibility, so you throw up all over the Internet using information you pretty much know to be forged. You're dumping trash in your neighbor's yard. That's a jerk thing to do; stop it!
Before, I used to work for a big ISP that only serviced companies and the setup was similar there, we had this huge Sun Enterprise cluster to accept incoming email for our clients, and then sent the emails to each customer's dedicated server without having any control over them.
I'd like to have some sympathy, but it's really hard to because you're part of the problem. Because you cannot architect a relaying system well enough, everyone else must suffer? I don't think that is a good answer. I think dumb relays are a dated concept and are long overdue for a quick death.
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.
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. 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.
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.
Everyone who could possible address the situation but does not gets a bit of my bile. There are clearly steps you can take to eliminate improper bouncing.
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.
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.
If spammers gave a fuck about valid emails, there wouldn't be so much bouncing and forged From headers in the first place! And let's hear you whistle that same tune when the ever increasing loads of spam turn your blue moon rarity to a daily sunset certainty.
It's not that simple. If you want to figure out that you can't deliver the message, you have to check. Checking takes computer resources. Now everyone has a really easy way of DoS'ing your server.
That doesn't make sense. It has to check anyway in order to deliver the message. A bounce means additional work of storing the entire message (instead of giving the error as soon as To header is found invalid) after accepting it, and then the bandwidth usage to bounce it. The cost of a bounce is at least double the cost of an error.
Furthermore, by returning 550 in the SMTP session, you've given criminals an easy way to search for valid email accounts.
If spammers still cared about address validation, they wouldn't be forging the From in the first place. I don't think any have cared about having "good" addresses for at least the last 2 years.
Accepting and then bouncing the messages remains the more secure and better performing solution. (Even when it's a 'Joe job' unfortunately.)
Your reasoning has been shown to be incorrect. Please adjust your world view accordingly. Thank you!:-)
What strikes me is that the major problem is not the spammers doing direct DoS attacks on the targets, but that they're using brain-dead behavior of mail servers to pull off DDoS attacks. If you control an MX, please configure it to issue a 550 error during the connection if you can't deliver the message instead of accepting it and then bouncing to what you almost certainly know is an innocent party. A party who is not the sender of the message, by the way, 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. Please be a friendly network neighbor and stop bouncing spam.
Sorry, but it is incredibly naive of you to assume that only "computer idiots" fall for these scams.
No, that is instead an incredibly accurate statement. The dirty secret is that 90% of users are "computer idiots", despite their feeling otherwise. It's just like how the vast majority of people think they're above average drivers.
They are very convincing... stealing all the branding of a legit informational email. I'll tell you, my mom and dad just cannot tell the difference between http://www.citibank.com/signup/account.jsp and http://www.citibank.com@192.168.0.1/acct.jsp.
Then that would then make them computer idiots. But that shouldn't even matter. It should be a simple issue of common sense. These scams contain any number of logical fallacies, mostly in the use of threat and authority in an attempt to be convincing.
These scams can be compelling to people who don't understand that ALL email should be untrusted, and that all URLs within email should be untrusted, and that all forms that you fill out should be untrusted.
In other word, compelling to idiots. And not just computer idiots, but general idiots. This whole thing has nothing to do with computers. If someone calls on the phone claiming to be from Citibank and demanding information, do you just give it to them? What if it's just a guy on the street in a suit with a name tag that says Citibank and a clip board? The email is no different a scam.
A lot of people like to bitch and moan about patent stupidity when someone tags "on a computer" to an old idea, but here you are trying to claim there is a significant difference between email and other types of social contract. That is just not the case. If your parents fall for a "give me your credit card number or spoooooooky bad things are going to happen!" scam, they are idiots. If you fail to acknowledge that, the problem might just have a genetic component.
AT&T has asked their customers, partners, and business clients to provide them with IP addresses of their mail servers.
Call me dense, but why not simply accept mail only from registered mail handlers? I would also do the filtering based on the connecting server's domain MX and the From header's domain MX; neither is registered, you give a 550 error. That would stop 99% of the spam (that I get, at least) right there. Especially the virus spam that tries to turn any random Windows box into an SMTP server.
oh great.. So now we would get hard copy versions of spam (in addition to the regular junk mail already receiving) along with the digital copies?
You're going to have to explain your logic because I'm not following. You get spam because it's cheap, not just because it's easy to find your address. I have a big white book sitting across the room that gives me hundreds of thousands of names and addresses, but that doesn't make sending a message to them all a cheap thing to do. If a spammer wanted to spend a dollar to contact you via post using a domain administrative contact, they already can. Making the domain a valid addressing format by the USPS changes nothing.
it's like if the USPS wouldn't let people send to you unless you registerd your address with them
Not to sound like I'm on Verisign's side, but wouldn't that be worth a small fee: to address physical mail to just "foobar@example.com" (or whatever) and have the USPS route that to a registered physical address? I think it would be brilliant if they were to implement that now, either with their own registration system or via pointers using the current domain name administrative contact. My business would certainly pay $15/year for that.
If they spew out fake spam which can only be meant for slanderous purposes, would you really expect them to *not* be in the virus game. Almost all these Windows viruses, if you hexdump them, have smtp capability.
Then it is suitably ironic that SpamCop does not allow reporting of virus-originated spam. If there is some connection between Sobig (and other Windows virus email) and spam fighting sites being attacked, then I would also think that SpamCop isn't that much farther down on the list of attacks, too. I never understood why these block lists were so against regular spam but allowed messages containing much more damaging exploits to flow freely in exponentially increasing amounts. Looks like that policy is biting them all in the ass now; time to change your battle plan, guys, and shithammer all abusive email.
Wrong. The people selling the crap aren't the spammers, they are the spammers' customers. If there are 1000 people who have access to insert-quack-product-here, all each of them has to do is one spam run just trying to make a profit and your inbox will be bulging. Multiply that by the number of questionable products that can be hawked for 3 easy payments of $19.95 and you're absolutely drowning in spam. The phenomena feeds itself at some point because if someone has a product and keeps getting spam from competitors, they just might hire a spammer to see what profits they're missing out on. Even if absolutely nobody sells a single product, the spammers make money and the spam keeps coming. This will go on like all MLM scams until something in the system burns out; if you can predict what that is (other than simply "money") you'll be a hero to many.
Slashdot Mirror
It is one or the other. It is impossible to increase security without reducing anonimity.
Rubbish. Anonymity comes within a context. If you give all your friends keys to your apartment, that doesn't necessarily tell you which individual was nice enough to drop off your mail and water your plants while you were on vacation. Similarly, if you sent me a key in the mail, you will have extended your web of trust, but completely anonymously; neither you or your friends know who I am seen in your apartment.
For example, there is not yet a possibility to only receive email from people that have revealed their identity with a trusted third party. I am affraid that is mainly a problem of legacy that a secure email protocol has not been deployed yet.
I'd say you're wrong here, too. SPEWS and other blocklists are examples of exactly that kind of trust issues being applied to current mail systems.
If you don't vote, then guess what? You don't get the right to bitch and moan when things don't go the way you want them to, plain and simple.
George Carlin has a hilarious routine that argues just the opposite: those that participate in a system they know to be wrong have no right to complain when it behaves as expected. Only those who do not vote can reasonably say they are not responsible for the misdeeds of those who have been elected to office.
It's fucked up, this political system we have, but at this point in time our only voice is by voting.
If you really believe that is your only voice, you are as powerless as those you vote for want you to be. If you instead believe your cause is just, revolution is possible. That may sound like terrorism to some, but I shouldn't have to point out to anyone on Slashdot that from the perspective of England, the actions in the American Colonies were just that. Or, to quote an American President 40 years dead: "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John Fitzgerald Kennedy
The world is a big place. You ought to get out and see more of it.
This is an odd statement. The truth is that those who actually do get out and see the world are those most exposed to the problems that miscommunication causes. Far too many people tie their culture to their communication and are unwilling to change. If most countries can seem to standardize on the metric system without much problem, why can't they all standardize on a language (any single language; not necessarily English)? If we can all share Euros, why can't we all share the same word for money?
What this reminds me of is how the Feds are made to work in Neal Stephenson's Snow Crash: the first ones in in the morning take the desks nearest the door and management can tell at a glance who's the most dedicated to the job.
Which, of course, is based on the old classroom practice of sitting at the front if you wanted to get teacher's attention. Like you say, though, a company is screwed if their management takes those shortcuts to evaluate who the eager employees are. Sometimes the person coming in early isn't the best employee, but merely the one that has to come in early to put in a day the company considers productive. There were jobs where I was allowed a number of times to skate in just before lunch without punishment simply because I was doing more than enough in the hours that I was there to justify my salary.
And even if I were at a company that evaluated you based on your sitting position, I'd sit in the back. I sat in back in class so that I could take in the whole class; simply having teacher's attention often wasn't enough to keep me interested in the subject, especially if teacher was moving slow for other students on something I already understood. I'd sit in the "back" in a desk pool simply because it would increase my chance of getting the same desk every day, and then all that "no personal items" BS would have less effect on me.
You know, it might be best to avoid words like "A", "The" "Alternative" (non-plural) when you decry the existence of a monoculture . . .
That only shows how timely the definition of a supercomputer is. 100 common desktop machines are very uncommon and obsolete 3 years from now.
Right. I recall Apple making a big stink a few years back about being a desktop supercomputer when they hit 1 GFLOPS, or whatever the benchmark was that initially established the first supercomputers. What makes a computer "super" while Moore's law is still being met will definitely change over time.
I think energy efficiency (MOPS/Watt) is a very relevant metric.
Only inasmuch as electricity costs money, and those costs can be compared to the cost of pushing more horsepower at the problem. I mean, if you have some calculations that daily require a 1 TFLOPS cluster (say some weather prediction), it doesn't much matter if you can get a .5 TFLOPS cluster that consumes 75% less power. Yeah, in theory you could get two, but there are coordination costs and scaling inefficiencies that would have to be dealt with so that in order to actually see 1 TFLOPS from the the second architecture it might end up being less efficient and requiring more energy.
All I'm saying is that if they want to claim any sort of efficient supercomputer, they have to have something on the Top 500 list and then worry/brag about what kind of low power consumption it has.
. . . might there be other metrics that might be important to supercomputing, rather than relying solely on processing speed?
No. I have a rock that can sit and do nothing, consuming considerably less than even 5.2kW. You can talk efficiency and bang-for-buck all you like, but if you don't benchmark faster than (roughly) 100 common desktop machines, you don't get to call yourself a supercomputer.
CD's are not a good way to archive anything.
No single media of any kind is a good way to archive anything. Afterall, that's exactly what got you into trouble in the first place. If you expect the one CD to last 25 years then you've learned nothing from your tape experience. If you only have one copy of something, you have a single point of failure. Anything really important should be encoded in multiple formats written to multiple media and stored in multiple locations.
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.
Do you have ADD or something? There are two discussions going on and you seem unable to focus on one at at time. The first is regarding your dumb relaying server and the second is what a smarter server could do.
All of which is designed to make sure bounces are successfully returned to the sender if the mail is undeliverable.
This has become tiresome. How many times do I have do point out that you are not returning anything to the sender with your crappy bounces. You are misdirecting message to a third party: whoever got forged into the From header. I'm done trying to explain that point to you. Take your medication before reading and responding already!
Most MTA software doesn't do what you just described.
Holy fuck, that's why the thread started in the first place! Most servers are lazy outdated pieces of shit. The were constructed in a time when the Internet was a happy academic playground. My whole complaint is that RFCs allow them to better address attempted abuse.
Systems following SMTP RFCs do not propagate 550 errors.
They are not prevented from doing so, either. Just because you have a "reference" implementation in sendmail (or whatever) that is easy to install doesn't make it the last word on what a server can do. Just admit you're a lazy admin and stop trying to hide behind a manufactured understanding of RFCs.
EVEN IF MY RELAY RETURNS A 550, THE SPAMMER'S RELAY WILL GENERATE A BOUNCE TO THE REVERSE-PATH.
What a shitty excuse. Just because there might be some other crap server in the chain is no reason you can't keep your own house clean. If I get garbage from a server, I can block it; wouldn't you prefer I block the spammer's relay than your server?
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.
Oh, please. Admins are doing far less than is allowed. They're mostly just lazy fucks who install something off the shelf to handle mail without too many hassles.
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.
On the contrary, I have obviously been more responsible in my mail administration than you have. I know "how e-mail works in the real world"; it doesn't work. It's bloody teetering on the brink of destruction. If your not going to take some responsibility in cleaning it up, if you're going to twist RFCs to favor spammers, damn straight you're a foe.
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.
You still fail to get that the whole point is that how things "ACTUALLY work" is broken. How very sad for you and your users.
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.
For future reference, when someone informs you of an updated RFC which you hadn't bothered to read for the last 2 years, read the fucking thing. Not just the section that you think supports your point, but the whole thing including the sections that might be less supportive. 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.
Where did you get the idea that 550 errors propagate?
On your systems they clearly don't, but we've already established you're a spam-friendly asshole. 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.
So, tell me again how bounces are not required? Note use of the word "must" in that sentence.
It doesn't say "you must send the message to an unrelated third party that you know damn well was forged". It just says a notification must be sent following a certain procedure. That procedure allows you to direct that notification inward where it belongs, which I have already noted is the only proper thing for a dumb server to do. Can the RFC be interpreted to allow you to be a jerk? Yes. Does that mean you have to be a jerk? No.
Rewriting the reverse-path to either null or the downstream postmaster, as you suggest, is clearly a violation of the RFC.
Since you're still reading 821, I don't know why I bother with you. All I know is that 2821 allows for exactly what I say, interpreting your dumb relay as a point of final delivery. It is allowed. You don't have do be a prick and bounce the joe-job, so don't do it.
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.
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. Only what you do is "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.
That is likely the quickest psychotic break I've ever seen. In one sentence you're saying the sender is intending a message to be lost and in the next you're talking about that as the legitimate use of mail. It's clear you're trying to see things not from the perspective of a responsible admin, but as a spammer. Way to out yourself, genius.
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?
I'm not suggesting, I'm precisely stating what I want. You want to put up a dumb relay? You had better make it totally stupid. 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.
People generally like to be notified if they make a typo in the address when they are sending a time-critical message.
But your bounces don't do that. They notify the From address. What if there was a typo there, too? The only way you can properly notify the actual sender is a server error.
Not to mention that bounces are required by RFCs
Wrong. Did you not even read my initial message? What your dumb server really should do is set the Return-Path to either null or the postmaster of the system you're relaying to. Again, if you cannot reasonably return a server error on non-delivery, you can not reasonably bounce a message either. A dumb relay should be dumb, and not pretend it is smart enough to do more than shuffle things inward.
You're calling me an incompetent admin?
No, I'm just pointing out that's what you're demonstrating. Stop defending outdated, lazy behavior and fix your systems.
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.
What the hell are you talking about? Detection of spam, or any other non-delivery issues, is a separate issue from the response. A joe-job happens when a server accepts a message it cannot deliver and it then bounces to a forged From header. My initial solution stands: if you do detection before fully accepting the message it allows you to respond with a proper error. I'm not sure why you find that so difficult to see.
Congratulations! You have eliminated .000005% of the joe-job problem!
No, I have eliminated 100% of my abusive messages. If you can't show me the same courtesy, if you continue to send abusive bounces, you might just find yourself unable to connect at all in the future. So stop being an ass and fix your server so we can all deal with the spammers themselves instead of infighting.
OK, I'll take the time to spell it out for you.
Nice and condescending right off the bat. I like that. 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.
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
Irrelevant. I don't care if you have a host for every email and a 20 relay tree to reach them. Manage the setup properly and stop accepting messages such that you bounce improperly.
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.
Also irrelevant. Again, your internal structure does not in any way require you to send abusive bounces.
3) a dumb relay is the simplest, most secure, nearly maintenance free method of getting that mail inside your protected network.
Not true, plus it makes you a real asshole for everyone else on the Internet. Being a lazy fuck who doesn't care is not a bullet point you would want to broadcast. All you get is simple, not secure or reliable. If you disagree, please feel free to "spell it out" further.
If the downstream gives a 550 error upon relaying, the relay host bounces the message anyway. Your "solution" doesn't work.
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.
Your problem is that the person who spoofed the reply-to is the one who lost it.
No, your problem is that you accepted the message for delivery prematurely. Then you found you couldn't actually live up to your responsibility, so you throw up all over the Internet using information you pretty much know to be forged. You're dumping trash in your neighbor's yard. That's a jerk thing to do; stop it!
Before, I used to work for a big ISP that only serviced companies and the setup was similar there, we had this huge Sun Enterprise cluster to accept incoming email for our clients, and then sent the emails to each customer's dedicated server without having any control over them.
I'd like to have some sympathy, but it's really hard to because you're part of the problem. Because you cannot architect a relaying system well enough, everyone else must suffer? I don't think that is a good answer. I think dumb relays are a dated concept and are long overdue for a quick death.
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.
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. 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.
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.
Everyone who could possible address the situation but does not gets a bit of my bile. There are clearly steps you can take to eliminate improper bouncing.
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.
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.
If spammers gave a fuck about valid emails, there wouldn't be so much bouncing and forged From headers in the first place! And let's hear you whistle that same tune when the ever increasing loads of spam turn your blue moon rarity to a daily sunset certainty.
It's not that simple. If you want to figure out that you can't deliver the message, you have to check. Checking takes computer resources. Now everyone has a really easy way of DoS'ing your server.
That doesn't make sense. It has to check anyway in order to deliver the message. A bounce means additional work of storing the entire message (instead of giving the error as soon as To header is found invalid) after accepting it, and then the bandwidth usage to bounce it. The cost of a bounce is at least double the cost of an error.
Furthermore, by returning 550 in the SMTP session, you've given criminals an easy way to search for valid email accounts.
If spammers still cared about address validation, they wouldn't be forging the From in the first place. I don't think any have cared about having "good" addresses for at least the last 2 years.
Accepting and then bouncing the messages remains the more secure and better performing solution. (Even when it's a 'Joe job' unfortunately.)
Your reasoning has been shown to be incorrect. Please adjust your world view accordingly. Thank you! :-)
What strikes me is that the major problem is not the spammers doing direct DoS attacks on the targets, but that they're using brain-dead behavior of mail servers to pull off DDoS attacks. If you control an MX, please configure it to issue a 550 error during the connection if you can't deliver the message instead of accepting it and then bouncing to what you almost certainly know is an innocent party. A party who is not the sender of the message, by the way, 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. Please be a friendly network neighbor and stop bouncing spam.
Sorry, but it is incredibly naive of you to assume that only "computer idiots" fall for these scams.
No, that is instead an incredibly accurate statement. The dirty secret is that 90% of users are "computer idiots", despite their feeling otherwise. It's just like how the vast majority of people think they're above average drivers.
They are very convincing... stealing all the branding of a legit informational email. I'll tell you, my mom and dad just cannot tell the difference between http://www.citibank.com/signup/account.jsp and http://www.citibank.com@192.168.0.1/acct.jsp.
Then that would then make them computer idiots. But that shouldn't even matter. It should be a simple issue of common sense. These scams contain any number of logical fallacies, mostly in the use of threat and authority in an attempt to be convincing.
These scams can be compelling to people who don't understand that ALL email should be untrusted, and that all URLs within email should be untrusted, and that all forms that you fill out should be untrusted.
In other word, compelling to idiots. And not just computer idiots, but general idiots. This whole thing has nothing to do with computers. If someone calls on the phone claiming to be from Citibank and demanding information, do you just give it to them? What if it's just a guy on the street in a suit with a name tag that says Citibank and a clip board? The email is no different a scam.
A lot of people like to bitch and moan about patent stupidity when someone tags "on a computer" to an old idea, but here you are trying to claim there is a significant difference between email and other types of social contract. That is just not the case. If your parents fall for a "give me your credit card number or spoooooooky bad things are going to happen!" scam, they are idiots. If you fail to acknowledge that, the problem might just have a genetic component.
AT&T has asked their customers, partners, and business clients to provide them with IP addresses of their mail servers.
Call me dense, but why not simply accept mail only from registered mail handlers? I would also do the filtering based on the connecting server's domain MX and the From header's domain MX; neither is registered, you give a 550 error. That would stop 99% of the spam (that I get, at least) right there. Especially the virus spam that tries to turn any random Windows box into an SMTP server.
oh great.. So now we would get hard copy versions of spam (in addition to the regular junk mail already receiving) along with the digital copies?
You're going to have to explain your logic because I'm not following. You get spam because it's cheap, not just because it's easy to find your address. I have a big white book sitting across the room that gives me hundreds of thousands of names and addresses, but that doesn't make sending a message to them all a cheap thing to do. If a spammer wanted to spend a dollar to contact you via post using a domain administrative contact, they already can. Making the domain a valid addressing format by the USPS changes nothing.
it's like if the USPS wouldn't let people send to you unless you registerd your address with them
Not to sound like I'm on Verisign's side, but wouldn't that be worth a small fee: to address physical mail to just "foobar@example.com" (or whatever) and have the USPS route that to a registered physical address? I think it would be brilliant if they were to implement that now, either with their own registration system or via pointers using the current domain name administrative contact. My business would certainly pay $15/year for that.
If they spew out fake spam which can only be meant for slanderous purposes, would you really expect them to *not* be in the virus game. Almost all these Windows viruses, if you hexdump them, have smtp capability.
Then it is suitably ironic that SpamCop does not allow reporting of virus-originated spam. If there is some connection between Sobig (and other Windows virus email) and spam fighting sites being attacked, then I would also think that SpamCop isn't that much farther down on the list of attacks, too. I never understood why these block lists were so against regular spam but allowed messages containing much more damaging exploits to flow freely in exponentially increasing amounts. Looks like that policy is biting them all in the ass now; time to change your battle plan, guys, and shithammer all abusive email.
Wrong. The people selling the crap aren't the spammers, they are the spammers' customers. If there are 1000 people who have access to insert-quack-product-here, all each of them has to do is one spam run just trying to make a profit and your inbox will be bulging. Multiply that by the number of questionable products that can be hawked for 3 easy payments of $19.95 and you're absolutely drowning in spam. The phenomena feeds itself at some point because if someone has a product and keeps getting spam from competitors, they just might hire a spammer to see what profits they're missing out on. Even if absolutely nobody sells a single product, the spammers make money and the spam keeps coming. This will go on like all MLM scams until something in the system burns out; if you can predict what that is (other than simply "money") you'll be a hero to many.
Not bilking your citizens of their money does not constitute a "cost" or "loss" on your part.