Only dedicated citizens and vocal consumers will be able to turn the tide of the privacy battle...
Not even they will be able to make any difference, because in order for them to make a difference they have to gain favorable media exposure. But the media is owned by the very corporations that are the root of the problem.
right now the corporations are winning.
There's no way the corporations can lose. The system as it is right now is completely airtight, because the corporations, through the media they own, control the exposure of ideas to the masses. Only when the broadcasts of an individual have the same chance of being seen as the corporate-owned media will this situation change. And it'll never get there, because the corporations ultimately control all communications channels that matter, from broadcast radio and TV to high-speed internet access. They will pass laws against anything they cannot control.
When there's no way to get from here to there, then "there" is a possibility that can never happen.
We, as people, had better take as much advantage of the freedom we have as we can, because we'll lose most of those freedoms very soon.
Only dedicated citizens and vocal consumers will be able to turn the tide of the privacy battle...
Not even they will be able to make any difference, because in order for them to make a difference they have to gain favorable media exposure. But the media is owned by the very corporations that are the root of the problem.
right now the corporations are winning.
There's no way the corporations can lose. The system as it is right now is completely airtight, because the corporations, through the media they own, control the exposure of ideas to the masses. Only when the broadcasts of an individual have the same chance of being seen as the corporate-owned media will this situation change. And it'll never get there, because the corporations ultimately control all communications channels that matter, from broadcast radio and TV to high-speed internet access. They will pass laws against anything they cannot control.
When there's no way to get from here to there, then "there" is a possibility that will never happen.
We, as people, had better take as much advantage of the freedom we have as we can, because we'll lose most of those freedoms very soon.
Only dedicated citizens and vocal consumers will be able to turn the tide of the privacy battle...
Not even they will be able to make any difference, because in order for them to make a difference they have to gain favorable media exposure. But the media is owned by the very corporations that are the root of the problem.
right now the corporations are winning.
There's no way the corporations can lose. The system as it is right now is completely airtight, because the corporations, through the media they own, control the exposure of ideas to the masses. Only when the broadcasts of an individual have the same chance of being seen as the corporate-owned media will this situation change. And it'll never get there, because the corporations ultimately control all communications channels that matter, from broadcast radio and TV to high-speed internet access. They will pass laws against anything they cannot control.
When there's no way to get from here to there, then "there" is a possibility that will never happen.
We, as people, had better take as much advantage of the freedom we have as we can, because we'll lose most of those freedoms very soon.
I still think that David Brin has it right - personal data will get collected, collated, etc; what's important is that you be able to see what's being done with your data, and to make sure that everyone gets the same treatment - no exceptions for corporations, governments, politicians, etc.
That would be nice, but it will never happen. In fact, I'd argue that the system as it is right now makes it impossible.
An imbalance of information gives power to the person with more information. The people in power will never give up any advantage they might currently have, or any advantage they might gain later. Since personal data will inevitably be collected, it immediately follows that the people in power will make sure that it is collected in such a way that they gain power from it -- and that means that they will never allow a transparent society to happen. What will happen instead is that the information will be available to those with power and unavailable to those without power.
So if David Brin has any hope at all that the transparent society will happen, then he is far too much of an optimist, and needs a dose of reality. Because reality wins every time. And the reality in this case is that we're all screwed. Get used to a global police state, because it's going to happen.
Additional filters would be required. This means additional work and additional CPU cycles
Oh, come on. Compared to the amount of additional work and additional CPU cycles currently used to fight spam, this ain't shit.
Of course, this isn't even taking into account the number of non-externally accessable MTAs that would have to somehow be accounted for, or for any of the (multi-)national ISPs which have upwards of 50+ outgoing MTAs for their clients. That's 50 (FIFTY!) extraneous connection attempts PER E-MAIL to reach a valid MX. I'm through mincing words; Your solution is not viable, short-sighted, and appears to be based almost entirely on ignorance.
Multinational ISPs are the least of your worries. If they have 50+ outgoing MTAs, then they have enough incoming MTAs, scattered in various geographic areas, that the probability of all of their incoming MTAs being unreachable is small enough to not worry about. Those 50+ extraneous connection attempts per email occur only when ***ALL*** of the valid MXes are unreachable. In other words, when there are no valid MXes to reach!! I don't know what's up with you worrying about a bit of additional traffic being generated in an unusual case. Sounds to me like you just don't like the proposal and are picking nits.
But if you really want, we can define a magic MX priority number (say, 65535) that will be interpreted to mean "this is a mail sender, so don't bother sending email using this MX record". We're having to make minor changes to the MTA code anyway so there's nothing stopping us from doing this. But I haven't thought through the implications of doing this yet (particularly as regards possible email loops), so it's only a tentative suggestion.
Frankly I'd prefer to define an entirely new DNS record, actually, and the only reason I didn't initially propose doing that is that I don't see any chance of that happening. But perhaps doing that would make the rest of the scheme more palatable to more people than using MX records would.
You'll note that in the case where no MX records are found, an A RR pointing to the name is treated as an implicit MX with a preference of 0.
Yeah...but that's for the recipient. My scheme implies that the sender has to be an MX (and thus have an MX record) for the domain. Yes, this automatically implies that receivers will be required to have MX records now, too. So?
If you're trying to say that my scheme will require some people to make some possibly inconvenient configuration changes to their domain, then you're absolutely correct. TANSTAAFL. There isn't a solution to the spam problem anywhere that won't be an inconvenience to some system administrator somewhere. But I can tell you this: the solution I propose will be less painful to implement than any of the other ones that have been proposed, because my proposal is merely a convention. In terms of the code changes to the MTAs, it'll take no more effort to implement than blacklists did.
If you can offer a better solution, then please do so.
Why can't you simply relay your mail through your provider?
There could be any number of reasons (each of which may or may not be applicable for any given provider):
Their email relays are unreliable.
Their email relays require that you use their domain as your address and not your own.
Their email relays scan your email and refuse to relay it if it doesn't conform to their guidelines (i.e., they act as a censor).
There are probably others, but those are the ones I can think of just off the top of my head.
But again, why should I have to pay extra just to use my own equipment? Why should sending email using your own equipment be a "premium service"? I suppose you're going to be telling us next that being able to surf websites the provider doesn't like (for instance, their competition's websites) should also be a "premium service"??
So we're supposed to double our MX records for all zones and maintain filters for all incoming and outgoing servers, because we've implemented falsified MX records in our zone files.
You only need filters on your outgoing servers. What, you don't have firewalls in front of your outgoing servers that block (or, better, reject) incoming SMTP already? What kind of moron are you if you don't?
So now if my primary, incoming MX goes down, my outgoing MX (which, by your reasoning, has incoming mail blocked/DENY'd) will have all incoming mail pointed at it. So now, rather than returning a timely error message and having mail destined for my domains sit in a 'Delayed' or 'Deferred' state at the transport MTAs, they have to try entire additional step(s), thereby doubling the wasted bandwidth amd causing more problems than it solves.
What "timely error message"? Your incoming MX is down, so email to your domain has already been delayed. A message typically isn't going to be sent to the sender about it until a few days have passed. Mail for your domain still sits in a "Delayed" or "Deferred" state, it just takes a little more wall clock time for it to get that way. And if you're so horribly concerned about this delay, then set up the firewall in front of your outbound MX to reject (so a TCP RST packet gets sent back when a TCP SYN is received) incoming SMTP instead of simply dropping it. And you consider this a problem???
And "wasted bandwidth"? By TCP connection attempts to unreachable hosts, and then only when your incoming MX is unreachable? That's 10 or so short TCP SYN packets per connection attempt at most. "Wasted bandwidth" my ass. That's going to be a problem only if you're having trouble keeping your incoming mail server up, in which case I'd argue that you've got bigger problems to worry about than a little "wasted bandwidth" from this scheme.
The only reason I suggested using MX records instead of defining an entirely new DNS record (which is really the right way to do this) is that the latter requires definition of a new record, which requires going through the standards process, etc. The use of MX records can be done right now.
Nice idea, but it would mean that your inbound and outbound mail server(s) both have to have the same IP address.
Not at all. You can have multiple MX records associated with a domain. So what you do is set up the systems that you want acting as inbound mail servers with high-priority MX records and the systems you want acting as outbound mail servers with low-priority MX records. Then you block inbound SMTP traffic to the outbound mail servers (you're doing that already anyway, right?).
End result: when someone tries to send email to you, they'll try the high-priority MXes first, and as long as those systems are reachable they won't even try to send mail to your low-priority MXes. And even if the high-priority ones aren't reachable, the low-priority ones aren't either because you're blocking inbound SMTP to them.
So the MX issue isn't an issue, as long as people understand that their inbound servers have to have higher-priority MX records.
It would also break the situation which I am in whereby I send my outbound mail through the easynet SMTP server no matter which of the three domains I own it comes from. This is necessary because when I'm dialled into easynet, I can only relay my outbound mail through its servers (the other servers would see me as an external connection trying to SPAM).
No problem: just list easynet's SMTP server as a low-priority MX for your domains! The only problem with that is that if the inbound mail server(s) for your domains are unavailable, people will try to send them to easynet's server instead...not good. But the reason easynet makes you go through the trouble of using their mail server to begin with is to prevent you from sending spam...which is precisely what the method we're discussing addresses. In your case, since you're a dialup sender, you'll have to use a dynamic DNS service to handle the MX records, but that's the only real complication.
especially since there is only one paragraph in RFC 821 that even mentions "mail exchange" and not in any context that we're talking about
Arrgh. RFC821 is way out of date...should have been looking at RFC 2821. But looking at that only seems to strengthen my case:
The Mail eXchanger mechanisms of the domain name system [22, 27] (and section 5 of this document) are used to identify the appropriate next-hop destination for a message being transported.
(implying that if you receive email from a host, that host should either be a mail exchanger for the sender's domain, or the originating host itself)
... Servers MUST be prepared to encounter a list of source routes in the forward path, but SHOULD ignore the routes or MAY decline to support the relaying they imply.
and
SMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes.
...
When source routes are not used, the process described in RFC 821 for constructing a reverse-path from the forward-path is not applicable and the reverse-path at the time of delivery will simply be the address that appeared in the MAIL command.
Basically, it looks like the use of source routes is deprecated, and the only situation in which the source route will not be the sender is when it's null -- which should generally only happen when the message is a bounce message of some sort. I'd say in that case it would be acceptable to check the From: line using the same heuristics, even though the RFC says that the SMTP relay should never examine mail headers.
BS. You can always gets a proper IP address from a service that offers you reverse. It may cost you a hell of a lot more than a commodity DSL does but so what? If you want a premium service pay for it, I do as do many others.
So now the simple ability to send email to the rest of the world using your own equipment is a "premium service" and warrants a $500/month charge?!? I'm sorry, but I don't want to live in a world where I have to pay extra for the ability to use my own equipment!!
Nice try, but what you propose is completely unreasonable, especially when a less demanding solution exists.
This is complete bullshit and far worse than what AOL is doing now.
Really? Why? With the method I propose, if you want to send email, it means you either have to control your own domain or use your ISP's mail relay. With what AOL is doing, you're forced to use your ISP's mail relay and don't have any other options.
So how is what I propose worse than what AOL is doing now?
I agree, but doing so will be much more difficult than making minor changes to the MTAs.
So, you are indeed basically proposing a new standard, and *everybody* wanting to send mail to you will have to adopt it or it will be rejected.
Correct. But I'm not proposing a new protocol, which is what so many people seem to be proposing.
But don't you think it would be better to reject email from illegitimate senders than to reject email from both illegitimate and legitimate senders, as some are doing now? AOL (among others) is rejecting email from legitimate senders. I own my own domain and everything, and am thus a legitimate sender, but AOL will reject any email I send simply because I happen to have an IP address that I do not control and cannot control (my ISP gives me no choice here). By forcing me to use my ISP's email server as a relay, AOL is forcing me to submit myself to all sorts of possible nastiness, including censorship (it's their email server, they can refuse to relay whatever they want for any reason they want, right?).
This is why I believe the solution I propose is a better answer: at least it makes it much easier to identify legitimate senders.
You ignored a portion of my previous posting. MX records are not reliable points of source-address verification.
I'll say it again; MX records are not reliable points of source-address verification.
Could you be more specific? It's fine to make the claim that MX records won't do the job, but it's not useful to me or anyone else if you don't say why. Just saying "refer to the RFC" isn't sufficient (especially since there is only one paragraph in RFC 821 that even mentions "mail exchange" and not in any context that we're talking about).
Your proposal, my friend, would require an SMTP re-implementation.
Really? Which part of SMTP itself would have to be changed? At most the reverse-path would have to be parsed by the recipient and the recipient would have to verify that the connecting system is a valid MX for the last entry in the reverse-path.
I'm not arguing that no MTAs will have to change, only that the SMTP protocol itself doesn't need to be thrown away.
Blocking reverse is fine; make your ignorant ISP fix your service.
Blocking someone in such a way that they can't fix it is completely unacceptable. If you're going to block someone, at least do it on the basis of something that they can reasonably do something about. You could block them, for instance, for not being an MX for the domain they claim to be sending from. That's something they can fix, because they can get their own domain and make their system an MX if they wish.
Insisting that they have an IP address that reverses properly is unacceptable because they almost certainly don't have any control over the reverse zone they fall under.
If you think they can "make" their ignorant ISP fix the service, then you should (if you're an AOL customer) be able to make your ISP "fix" your service by forcing them to give you a static IP address. What's that? They don't offer that service, and you can't get service from anyone else? Bingo. Welcome to the real world.
For another way to fight spam, which I read on the Mimedefang mailing list, how about setting up a way for domain admins to specify valid smtp servers for a domain.
There is already a way to do this: the domain MX records. It's just that, right now, they're used only to identify SMTP receivers. I propose that we use them to identify senders as well, and look them up based on their "MAIL FROM" SMTP command (which isn't the same thing as the "From:" header). We check the "From:" line, too, but that would cause a lot more pain, I suspect.
So basically, I think we'll have a sort of "mini second tech bubble", except with one difference this time.. it won't be a bubble, it will be for real? Why? For one, because venture capitalists will be more demanding in terms of deciding who to float money to
Hate to break it to you, but it's the venture capitalists that caused the last bubble to burst to begin with.
Remember all those dotcom startups that were told to "grow now, worry about being profitable later"? Guess who told them that? Right: the VCs. Why were they told that? Because the VCs weren't interested in making the company viable for the long term, they were interested only in growing the company enough that it could go IPO, so they could cash out when the IPO took place and the company stocks shot through the roof for the first couple of weeks or so.
The bubble burst when non-VC stock investors got wise to the scam.
So what makes you believe that VCs will be any different the next time around? Their goal is to make as much money in as short a time as possible. If stocks start doing what they did last time around, you can bet big money the VCs will try the same shit as last time (with perhaps a slightly different twist to keep the non-VC stock investors off balance).
Wrong assumption: incoming SMTP server = outgoing SMTP server. Many large and small organizations use different machines to recieve and send mail via SMTP. In other words, you'll end up rejecting a huge (50-80?) percentage of legitimate mail.
Yes, that's how it is right now, and that's why spam is so much of a problem. Right now there's nothing to differentiate between a legitimate SMTP connection and an illegitimate one: anyone can pretend to be someone else and send email as if they were that someone else, and the recipient has no way of knowing that this is happening.
The method I describe is intended to fix this without requiring a completely new protocol. It's simply a convention that can be followed. And note that if you have systems that you want to send email from but which you don't want to receive email, you simply list them as low-priority MXes (so that your legitimate email receivers get sent to first) and then block SMTP traffic from the rest of the world to those outbound-only SMTP systems...something you'll be doing anyway if you have any brains.
So it's really simple: if you want to send email, you either have to use someone else's email system (such as your ISP's) as a legitimate relay or you'll have to buy and operate a domain. It's not that hard, but it's enough additional effort that it should eliminate a lot of the spammers that are out there.
Give me a Visa card with a $2000 limit and I can own about 200 domains inside of 24 hours. Considering SPAMmers are purchasing $750k houses with the proceeds from their efforts, I'd say that's not a huge problem.
The doamins aren't their only expense. Now they also have to pay for their own hosting as well, as well as for the DNS servers that will be authoritative for their domains. They won't be able to make nearly as much use of open relays because the domains associated with any open relays will be blacklisted as quickly as theirs (and the definition of an "open relay" becomes more complicated under my scheme anyway, because an open relay has to either claim that it's sending your email under its domain or it has to be listed as an MX for your domain).
Those 200 domains aren't going to last you very long...perhaps a couple of weeks once the blacklisting mechanisms become good (and note that blacklisting can happen on a local level now, too). So that $2000 you talk about grows to $50,000 over the course of a year. That's going to eliminate a lot of spammers.
Now consider what happens when SPAMmers start routinely issuing "MAIL FROM: <kcbrown@sysexperts.com>"
What happens when they do that is that the system they're connecting to looks up the MXes for sysexperts.com and -- surprise -- finds out that the IP address the connection is coming from doesn't match any of the MX records for sysexperts.com...and drops the connection right then and there. It doesn't register the sysexperts.com domain in the blacklist because there's no need: it's obvious that the connection was a forgery! The purpose of the blacklist is to eliminate domains that are successfully sending spam, i.e. the ones for which the connection address matches the MX lookup but for which the payload is still spam -- the domains that either belong to the spammers or which are open relays, in other words.
Spammers will be able to send email in your name just as they can right now, but only because the enforcement mechanism I describe operates on information from the "MAIL FROM" SMTP command and not the "From:" header. It would be possible to enforce it on the "From:" header, too, but that will cause a lot more inconvenience, since some people legitimately rely on the ability to define the "From:" header to be whatever they want.
Now, you may be right about the economic argument, but the technique I describe will simultaneously cost spammers more money (which is always a good thing) and more time and make it easier to fight spam at the same time, because blacklists will become a lot more effective (since now you can target domains instead of dynamically-assigned IP addresses) and a lot fairer (since you won't be targeting netblocks that could contain legitimate users). To relate back to the original article, because it'll completely eliminate the need to block IP addresses and will thus drastically reduce the need for ISPs to block SMTP (inbound or outbound).
By the way, I think it's ridiculous for ISPs to be blocking SMTP when they could easily limit the number of outbound SMTP connections originating from any of their IP addresses to something low enough to make spam impractical but high enough for legitimate use.
It's time for reform in the overall e-mail system, the only problem is that there's a huge installed user base that'd be forced to upgrade in order for a new e-mail protocol to work. It's gonna take something silly like this to get out of hand for that to happen.
You don't need a new protocol. The one we have will work fine.
What people need to do is stop trusting every email connection that's made, and instead insist that every email connection comes from a listed MX.
This is easy to do: check the MXes for the domain listed in the SMTP "MAIL FROM" command (not to be confused with the "From:" header in the email message itself) and reject the connection if the IP address of the connection doesn't match one of the listed MXes for the domain. If you want to send email from a system that isn't a real MX, list it as a low priority one and block incoming SMTP traffic to that box (something anyone with any brains will be doing anyway), so that all incoming email goes only to the MXes that can handle incoming email.
End result: it forces spammers to buy a domain (that won't last very long since it'll be blacklisted immediately if it starts sending spam), makes it easy to create useful blacklists that work, and ultimately significantly increases the costs of spamming. And finally provides a way of reliably ignoring open relays (because you can blacklist the domain associated with the open relay).
And all of this can be done now, with no changes to SMTP required at all.
So why are we all sitting around on our asses complaining about spam when a viable solution already exists?
In these times when the major media corporations suck at the tit of the ruling political party and largely publish only those items that the ruling political party wishes to be published
No, you've got it wrong. The media corporations aren't subservient to the government, they control it. It is they to whom the government gives its allegiance, because it is they who control the amount and nature of popular exposure any candidate will receive during an election run. And because the media corporations are corporations, and thus interested primarily in their own bottom line, they almost certainly sell their influence over the candidates to other corporations.
This relationship has gone on long enough that it's highly symbiotic: the elected officials, and thus ultimately everyone in government, depends on the media corporations for favorable public exposure, and the media corporations (and any corporation that does business with them) depend on the government for favorable laws.
This is why the government answers to the corporations and not the people: because today there is no real difference between the corporations and the government anymore.
Re:Refactoring does not depend on Eclipse: Emacs!
on
Eclipse 2.1 Released
·
· Score: 1
I'm paid to design and develop software (amongst other related things), not to learn to use a tool.
Huh? When you're paid to do a job, learning the tools to do the job (even if there are some of them that you don't end up using) is implied, because you simply can't do your job properly without knowing how to use the tools to do it, nor can you do your job well if you don't know enough about the available tools to make an intelligent decision about which ones are most applicable for the job at hand.
I wish I knew where this idiotic notion that you should be able to do your job without learning how to use the necessary tools comes from, but it seems that it's becoming more common over time -- a depressing thought, to say the least.
It's this thinking that's behind the belief people have that they should be able to use the computer, including all the programs on it, without having ever learned anything about it first.
If automobiles hadn't been around for so long, people would probably think that they should be able to get into a car and drive without learning anything about driving, too. It's probably only because the people who made the automobile into an integral part of our society weren't as lazy and stupid as people today that this notion never made it into the automobile culture...
Slashdot Mirror
Not even they will be able to make any difference, because in order for them to make a difference they have to gain favorable media exposure. But the media is owned by the very corporations that are the root of the problem.
There's no way the corporations can lose. The system as it is right now is completely airtight, because the corporations, through the media they own, control the exposure of ideas to the masses. Only when the broadcasts of an individual have the same chance of being seen as the corporate-owned media will this situation change. And it'll never get there, because the corporations ultimately control all communications channels that matter, from broadcast radio and TV to high-speed internet access. They will pass laws against anything they cannot control.
When there's no way to get from here to there, then "there" is a possibility that can never happen.
We, as people, had better take as much advantage of the freedom we have as we can, because we'll lose most of those freedoms very soon.
Not even they will be able to make any difference, because in order for them to make a difference they have to gain favorable media exposure. But the media is owned by the very corporations that are the root of the problem.
There's no way the corporations can lose. The system as it is right now is completely airtight, because the corporations, through the media they own, control the exposure of ideas to the masses. Only when the broadcasts of an individual have the same chance of being seen as the corporate-owned media will this situation change. And it'll never get there, because the corporations ultimately control all communications channels that matter, from broadcast radio and TV to high-speed internet access. They will pass laws against anything they cannot control.
When there's no way to get from here to there, then "there" is a possibility that will never happen.
We, as people, had better take as much advantage of the freedom we have as we can, because we'll lose most of those freedoms very soon.
Not even they will be able to make any difference, because in order for them to make a difference they have to gain favorable media exposure. But the media is owned by the very corporations that are the root of the problem.
There's no way the corporations can lose. The system as it is right now is completely airtight, because the corporations, through the media they own, control the exposure of ideas to the masses. Only when the broadcasts of an individual have the same chance of being seen as the corporate-owned media will this situation change. And it'll never get there, because the corporations ultimately control all communications channels that matter, from broadcast radio and TV to high-speed internet access. They will pass laws against anything they cannot control.
When there's no way to get from here to there, then "there" is a possibility that will never happen.
We, as people, had better take as much advantage of the freedom we have as we can, because we'll lose most of those freedoms very soon.
That would be nice, but it will never happen. In fact, I'd argue that the system as it is right now makes it impossible.
An imbalance of information gives power to the person with more information. The people in power will never give up any advantage they might currently have, or any advantage they might gain later. Since personal data will inevitably be collected, it immediately follows that the people in power will make sure that it is collected in such a way that they gain power from it -- and that means that they will never allow a transparent society to happen. What will happen instead is that the information will be available to those with power and unavailable to those without power.
So if David Brin has any hope at all that the transparent society will happen, then he is far too much of an optimist, and needs a dose of reality. Because reality wins every time. And the reality in this case is that we're all screwed. Get used to a global police state, because it's going to happen.
Inventions that are that are obsoleted that fast don't need patent protection.
Or spell, for that matter. :-)
(You got Peugeot right, but the other is spelled "Citroën").
Oh, come on. Compared to the amount of additional work and additional CPU cycles currently used to fight spam, this ain't shit.
Multinational ISPs are the least of your worries. If they have 50+ outgoing MTAs, then they have enough incoming MTAs, scattered in various geographic areas, that the probability of all of their incoming MTAs being unreachable is small enough to not worry about. Those 50+ extraneous connection attempts per email occur only when ***ALL*** of the valid MXes are unreachable. In other words, when there are no valid MXes to reach!! I don't know what's up with you worrying about a bit of additional traffic being generated in an unusual case. Sounds to me like you just don't like the proposal and are picking nits.
But if you really want, we can define a magic MX priority number (say, 65535) that will be interpreted to mean "this is a mail sender, so don't bother sending email using this MX record". We're having to make minor changes to the MTA code anyway so there's nothing stopping us from doing this. But I haven't thought through the implications of doing this yet (particularly as regards possible email loops), so it's only a tentative suggestion.
Frankly I'd prefer to define an entirely new DNS record, actually, and the only reason I didn't initially propose doing that is that I don't see any chance of that happening. But perhaps doing that would make the rest of the scheme more palatable to more people than using MX records would.
Yeah...but that's for the recipient. My scheme implies that the sender has to be an MX (and thus have an MX record) for the domain. Yes, this automatically implies that receivers will be required to have MX records now, too. So?
If you're trying to say that my scheme will require some people to make some possibly inconvenient configuration changes to their domain, then you're absolutely correct. TANSTAAFL. There isn't a solution to the spam problem anywhere that won't be an inconvenience to some system administrator somewhere. But I can tell you this: the solution I propose will be less painful to implement than any of the other ones that have been proposed, because my proposal is merely a convention. In terms of the code changes to the MTAs, it'll take no more effort to implement than blacklists did.
If you can offer a better solution, then please do so.
There could be any number of reasons (each of which may or may not be applicable for any given provider):
There are probably others, but those are the ones I can think of just off the top of my head.
But again, why should I have to pay extra just to use my own equipment? Why should sending email using your own equipment be a "premium service"? I suppose you're going to be telling us next that being able to surf websites the provider doesn't like (for instance, their competition's websites) should also be a "premium service"??
You only need filters on your outgoing servers. What, you don't have firewalls in front of your outgoing servers that block (or, better, reject) incoming SMTP already? What kind of moron are you if you don't?
What "timely error message"? Your incoming MX is down, so email to your domain has already been delayed. A message typically isn't going to be sent to the sender about it until a few days have passed. Mail for your domain still sits in a "Delayed" or "Deferred" state, it just takes a little more wall clock time for it to get that way. And if you're so horribly concerned about this delay, then set up the firewall in front of your outbound MX to reject (so a TCP RST packet gets sent back when a TCP SYN is received) incoming SMTP instead of simply dropping it. And you consider this a problem???
And "wasted bandwidth"? By TCP connection attempts to unreachable hosts, and then only when your incoming MX is unreachable? That's 10 or so short TCP SYN packets per connection attempt at most. "Wasted bandwidth" my ass. That's going to be a problem only if you're having trouble keeping your incoming mail server up, in which case I'd argue that you've got bigger problems to worry about than a little "wasted bandwidth" from this scheme.
The only reason I suggested using MX records instead of defining an entirely new DNS record (which is really the right way to do this) is that the latter requires definition of a new record, which requires going through the standards process, etc. The use of MX records can be done right now.
Not at all. You can have multiple MX records associated with a domain. So what you do is set up the systems that you want acting as inbound mail servers with high-priority MX records and the systems you want acting as outbound mail servers with low-priority MX records. Then you block inbound SMTP traffic to the outbound mail servers (you're doing that already anyway, right?).
End result: when someone tries to send email to you, they'll try the high-priority MXes first, and as long as those systems are reachable they won't even try to send mail to your low-priority MXes. And even if the high-priority ones aren't reachable, the low-priority ones aren't either because you're blocking inbound SMTP to them.
So the MX issue isn't an issue, as long as people understand that their inbound servers have to have higher-priority MX records.
No problem: just list easynet's SMTP server as a low-priority MX for your domains! The only problem with that is that if the inbound mail server(s) for your domains are unavailable, people will try to send them to easynet's server instead...not good. But the reason easynet makes you go through the trouble of using their mail server to begin with is to prevent you from sending spam...which is precisely what the method we're discussing addresses. In your case, since you're a dialup sender, you'll have to use a dynamic DNS service to handle the MX records, but that's the only real complication.
Arrgh. RFC821 is way out of date...should have been looking at RFC 2821. But looking at that only seems to strengthen my case:
(implying that if you receive email from a host, that host should either be a mail exchanger for the sender's domain, or the originating host itself)
and
Basically, it looks like the use of source routes is deprecated, and the only situation in which the source route will not be the sender is when it's null -- which should generally only happen when the message is a bounce message of some sort. I'd say in that case it would be acceptable to check the From: line using the same heuristics, even though the RFC says that the SMTP relay should never examine mail headers.
So now the simple ability to send email to the rest of the world using your own equipment is a "premium service" and warrants a $500/month charge?!? I'm sorry, but I don't want to live in a world where I have to pay extra for the ability to use my own equipment!!
Nice try, but what you propose is completely unreasonable, especially when a less demanding solution exists.
Really? Why? With the method I propose, if you want to send email, it means you either have to control your own domain or use your ISP's mail relay. With what AOL is doing, you're forced to use your ISP's mail relay and don't have any other options.
So how is what I propose worse than what AOL is doing now?
I agree, but doing so will be much more difficult than making minor changes to the MTAs.
Correct. But I'm not proposing a new protocol, which is what so many people seem to be proposing.
But don't you think it would be better to reject email from illegitimate senders than to reject email from both illegitimate and legitimate senders, as some are doing now? AOL (among others) is rejecting email from legitimate senders. I own my own domain and everything, and am thus a legitimate sender, but AOL will reject any email I send simply because I happen to have an IP address that I do not control and cannot control (my ISP gives me no choice here). By forcing me to use my ISP's email server as a relay, AOL is forcing me to submit myself to all sorts of possible nastiness, including censorship (it's their email server, they can refuse to relay whatever they want for any reason they want, right?).
This is why I believe the solution I propose is a better answer: at least it makes it much easier to identify legitimate senders.
Could you be more specific? It's fine to make the claim that MX records won't do the job, but it's not useful to me or anyone else if you don't say why. Just saying "refer to the RFC" isn't sufficient (especially since there is only one paragraph in RFC 821 that even mentions "mail exchange" and not in any context that we're talking about).
Really? Which part of SMTP itself would have to be changed? At most the reverse-path would have to be parsed by the recipient and the recipient would have to verify that the connecting system is a valid MX for the last entry in the reverse-path.
I'm not arguing that no MTAs will have to change, only that the SMTP protocol itself doesn't need to be thrown away.
Blocking someone in such a way that they can't fix it is completely unacceptable. If you're going to block someone, at least do it on the basis of something that they can reasonably do something about. You could block them, for instance, for not being an MX for the domain they claim to be sending from. That's something they can fix, because they can get their own domain and make their system an MX if they wish.
Insisting that they have an IP address that reverses properly is unacceptable because they almost certainly don't have any control over the reverse zone they fall under.
If you think they can "make" their ignorant ISP fix the service, then you should (if you're an AOL customer) be able to make your ISP "fix" your service by forcing them to give you a static IP address. What's that? They don't offer that service, and you can't get service from anyone else? Bingo. Welcome to the real world.
There is already a way to do this: the domain MX records. It's just that, right now, they're used only to identify SMTP receivers. I propose that we use them to identify senders as well, and look them up based on their "MAIL FROM" SMTP command (which isn't the same thing as the "From:" header). We check the "From:" line, too, but that would cause a lot more pain, I suspect.
Hate to break it to you, but it's the venture capitalists that caused the last bubble to burst to begin with.
Remember all those dotcom startups that were told to "grow now, worry about being profitable later"? Guess who told them that? Right: the VCs. Why were they told that? Because the VCs weren't interested in making the company viable for the long term, they were interested only in growing the company enough that it could go IPO, so they could cash out when the IPO took place and the company stocks shot through the roof for the first couple of weeks or so.
The bubble burst when non-VC stock investors got wise to the scam.
So what makes you believe that VCs will be any different the next time around? Their goal is to make as much money in as short a time as possible. If stocks start doing what they did last time around, you can bet big money the VCs will try the same shit as last time (with perhaps a slightly different twist to keep the non-VC stock investors off balance).
Yes, that's how it is right now, and that's why spam is so much of a problem. Right now there's nothing to differentiate between a legitimate SMTP connection and an illegitimate one: anyone can pretend to be someone else and send email as if they were that someone else, and the recipient has no way of knowing that this is happening.
The method I describe is intended to fix this without requiring a completely new protocol. It's simply a convention that can be followed. And note that if you have systems that you want to send email from but which you don't want to receive email, you simply list them as low-priority MXes (so that your legitimate email receivers get sent to first) and then block SMTP traffic from the rest of the world to those outbound-only SMTP systems...something you'll be doing anyway if you have any brains.
So it's really simple: if you want to send email, you either have to use someone else's email system (such as your ISP's) as a legitimate relay or you'll have to buy and operate a domain. It's not that hard, but it's enough additional effort that it should eliminate a lot of the spammers that are out there.
The doamins aren't their only expense. Now they also have to pay for their own hosting as well, as well as for the DNS servers that will be authoritative for their domains. They won't be able to make nearly as much use of open relays because the domains associated with any open relays will be blacklisted as quickly as theirs (and the definition of an "open relay" becomes more complicated under my scheme anyway, because an open relay has to either claim that it's sending your email under its domain or it has to be listed as an MX for your domain).
Those 200 domains aren't going to last you very long...perhaps a couple of weeks once the blacklisting mechanisms become good (and note that blacklisting can happen on a local level now, too). So that $2000 you talk about grows to $50,000 over the course of a year. That's going to eliminate a lot of spammers.
What happens when they do that is that the system they're connecting to looks up the MXes for sysexperts.com and -- surprise -- finds out that the IP address the connection is coming from doesn't match any of the MX records for sysexperts.com...and drops the connection right then and there. It doesn't register the sysexperts.com domain in the blacklist because there's no need: it's obvious that the connection was a forgery! The purpose of the blacklist is to eliminate domains that are successfully sending spam, i.e. the ones for which the connection address matches the MX lookup but for which the payload is still spam -- the domains that either belong to the spammers or which are open relays, in other words.
Spammers will be able to send email in your name just as they can right now, but only because the enforcement mechanism I describe operates on information from the "MAIL FROM" SMTP command and not the "From:" header. It would be possible to enforce it on the "From:" header, too, but that will cause a lot more inconvenience, since some people legitimately rely on the ability to define the "From:" header to be whatever they want.
Now, you may be right about the economic argument, but the technique I describe will simultaneously cost spammers more money (which is always a good thing) and more time and make it easier to fight spam at the same time, because blacklists will become a lot more effective (since now you can target domains instead of dynamically-assigned IP addresses) and a lot fairer (since you won't be targeting netblocks that could contain legitimate users). To relate back to the original article, because it'll completely eliminate the need to block IP addresses and will thus drastically reduce the need for ISPs to block SMTP (inbound or outbound).
By the way, I think it's ridiculous for ISPs to be blocking SMTP when they could easily limit the number of outbound SMTP connections originating from any of their IP addresses to something low enough to make spam impractical but high enough for legitimate use.
You don't need a new protocol. The one we have will work fine.
What people need to do is stop trusting every email connection that's made, and instead insist that every email connection comes from a listed MX.
This is easy to do: check the MXes for the domain listed in the SMTP "MAIL FROM" command (not to be confused with the "From:" header in the email message itself) and reject the connection if the IP address of the connection doesn't match one of the listed MXes for the domain. If you want to send email from a system that isn't a real MX, list it as a low priority one and block incoming SMTP traffic to that box (something anyone with any brains will be doing anyway), so that all incoming email goes only to the MXes that can handle incoming email.
End result: it forces spammers to buy a domain (that won't last very long since it'll be blacklisted immediately if it starts sending spam), makes it easy to create useful blacklists that work, and ultimately significantly increases the costs of spamming. And finally provides a way of reliably ignoring open relays (because you can blacklist the domain associated with the open relay).
And all of this can be done now, with no changes to SMTP required at all.
So why are we all sitting around on our asses complaining about spam when a viable solution already exists?
Told you so.
Maybe next time you'll listen when we warn you about such things.
No, you've got it wrong. The media corporations aren't subservient to the government, they control it. It is they to whom the government gives its allegiance, because it is they who control the amount and nature of popular exposure any candidate will receive during an election run. And because the media corporations are corporations, and thus interested primarily in their own bottom line, they almost certainly sell their influence over the candidates to other corporations. This relationship has gone on long enough that it's highly symbiotic: the elected officials, and thus ultimately everyone in government, depends on the media corporations for favorable public exposure, and the media corporations (and any corporation that does business with them) depend on the government for favorable laws.
This is why the government answers to the corporations and not the people: because today there is no real difference between the corporations and the government anymore.
Huh? When you're paid to do a job, learning the tools to do the job (even if there are some of them that you don't end up using) is implied, because you simply can't do your job properly without knowing how to use the tools to do it, nor can you do your job well if you don't know enough about the available tools to make an intelligent decision about which ones are most applicable for the job at hand.
I wish I knew where this idiotic notion that you should be able to do your job without learning how to use the necessary tools comes from, but it seems that it's becoming more common over time -- a depressing thought, to say the least. It's this thinking that's behind the belief people have that they should be able to use the computer, including all the programs on it, without having ever learned anything about it first.
If automobiles hadn't been around for so long, people would probably think that they should be able to get into a car and drive without learning anything about driving, too. It's probably only because the people who made the automobile into an integral part of our society weren't as lazy and stupid as people today that this notion never made it into the automobile culture...