Jump to content

The future of spoofed spam looks bad


potomuss

Recommended Posts

I've been reading about all these proposed changes with email to eliminate spoofed email and spam. Things like digital signatures and actually changing the smtp protocol which would make it impossible. Any opinions on which way would be the best way, if either?

Link to comment
Share on other sites

I am not sure but I think the biggest drawback is that the change for stmp protocol is expensive (so many things to change, new hardware, software, whatever). I can't think of a parallel example right now.

And the digital signature means that someone will be making money from registering them - look at the scandal with Verisign right now.

And many people will resist anything that makes the internet less free and open. I really liked living in a place where I never had to lock my doors or even take the key out of my car when I parked it and where people could have a fruit stand on the honor system and nobody was suspicious of a stranger. There are many people who remember an even freer and open internet than I do.

Maybe when this generation passes on - the fences will start catching on.

Miss Betsy

Link to comment
Share on other sites

Technically, at this point, the bottom line is that any change is going to take a long time to actually implement. A lot of this issue is in the plan for moving from IP4 to IP6, but the stall factor on that is trying to figure out just how the entire "net" is going to make the transition. Hardware changes, software changes, all balanced against the pocketbooks of all involved. And that's nothing as compared to the usual "which standard is going to be THE standard?" in making any great change. You bring up "digital signatures" ... There are dozens to choose from these days, and of course, none are compatible with the others . they don't cost the same, don't track the same, different databases, different identification requirements, and this concept has been around for a long, long time.

So even if a decision was made tomorrow as to "where the standard is going", there's going to be years of maintaining backwards compatibility by the major players, as it's going to take so long to convert enough of the net that simply going to the "new" standard doesn't turn "your" section of the net into an island. Thus the anticipated changes are a long way off.

And of course, now that I've committed those words to screen, the magic solution will appear from out of nowhere in the next half-hour <g>

Link to comment
Share on other sites

Whatever the solution it needs to address the cheap cost to send and the ease of forgery.

If we can't stop new `spam sending businesses' deciding to spam because it is so cheap to start, we are lost.

An example for authentication is PGP. It is technical to setup but would eliminate spam overnight if all emails had to be signed. This won't happen but something in the middle might.

Microsofts' pay-to-send and puzzle-to-send might address the cost of sending and who know maybe some lightweight authentication scheme could be implemented.

Each ISP could issue their own email signatutes to their clients. They are password protected and well behaved ISPs can revoke them if you spam through their network. Only signed email can transit their servers. Some heirarchy is built into the issuing authority/ISP so that each user can block by country/ISP/client. If you don't mind receiving unsolicited (but signed) email you could allow that in your own setup.

Link to comment
Share on other sites

example for authentication is PGP

which in some countries, the possession of is a one-way jail ticket.

Microsofts' pay-to-send

such a system once existed ... that you don't mention it kind of suggests how it worked out <g>

Only signed email can transit their servers

sounds awfully close to the current "model" of "only authorized traffic can transit" doesn't it? And how many ISPs are out there that still run a wide-open system?

Some heirarchy is built into the issuing authority/ISP so that each user can block by country/ISP/client

and that some do allow this already through the use of BL's and such says what? And that the capability does exist today and it's not a universal solution used / made available by all ISPs suggests what? And just look at all the traffic caused by ISPs that can't yet figure out how to configure their servers to meet RFC / standards that have been around for years.

Again, there's nothing wrong with all the ideas, it's just that the "net" isn't just the handful of U.S. military bases, universities, and a small number of U.S. Government contractors anymore ....

Link to comment
Share on other sites

I know this is blasphemy to some, but I'm all in favor of a Sender Permitted From, or SPF record added to the DNS structure. It would sort of be the opposite of the MX record that is already there really. It would be easy to support legacy wise for a while, as if a domain didn't contain an SPF record, you could allow it while people were converting over. Of course, much spam would get through in the mean time, but once it was enabled, it would get rid of a lot of the spam on the internet. The majority of sludge out their stems from abused proxies and trojaned computers. You could no longer hijack someone's computer and spew junk all over the place, you'd have to know the SMTP server for that person, and if they ever did get that good, it would be simple for the ISP to shut them down for TOS, and get their computer cleaned up. Combine SPF with SMTP-Auth becoming more of a standard, and then you *REALLY* minimize this possibility. This would also make domain (as opposed to IP) blocking a feasible option again, as even if someone did have a valid SPF and continued to spam all over the place, you could block on domain and be done with it since that IP is linked to the SPF record in their own DNS. This of course doesn't prevent spammers from buying tons of domains and setting up DNS for them, but it does cost them money, time, and effort to do this, and once a domain is used up (mostly blocklisted) it means having to fork over yet more money to continue spamming. Since spamming is only profitable because it is cheap, this would cut margins and possibly reclaim the net for the average user! :D

Link to comment
Share on other sites

SPF record added to the DNS structure

Exactly where and how would you insert this data into the existing DNS structure? Is DNS the exact item you're thinking of? The exercise of just tossing more bits into some field of the bitstream is one thing, but that all e-mail software would also have to be re-written to see and do something with this additional bit of data is a bit out therer, to say the least.

Link to comment
Share on other sites

Write a Virus/Worm to set up zombie PC's and send spam email.

Oh my, that's already been done - so how do you stop that? 

I explained that in my post. Since it didn't come from my domain's SMTP server, thus not matching my SPF record, it gets rejected.

Exactly where and how would you insert this data into the existing DNS structure?

I'd put it right after the MX records, since they're related. Now as for *technically* how it would get done, as far as where the 1's and 0's would go, that I am not gifted enough to begin to understand.

but that all e-mail software would also have to be re-written to see and do something with this additional bit of data is a bit out there

This is very true, but I think that's going to have to happen with ANY solution that comes about. This would be no different than MTA's adding the ability to check against an RBL though. In fact, it would be almost identical except that it would be automatic since you query the authoritative server for that domain based on the domain sent in the from address. IP of SMTP server doesn't match the domain? Forward to /dev/null.

Link to comment
Share on other sites

This would be no different than MTA's adding the ability to check against an RBL though.

Except that RBL's are not mandatory. You seem to be saying this new system would be mandatory.

The current system still works with the many ancient mTA's in use around the world. There is no requirement for an upgrade. Any solution that requires an upgrade of all MTA's will take years before it is ever to work (if that can even be accomplished). Just look at rDNS. I can not enable it at work becuase too many of the valid servers (~75%) sending us email were being rejected while the spammers had their configurations working and passing messages. The test run about 1 year ago lasted less than 1 day. I have heard of similiar problems recently, as well.

Link to comment
Share on other sites

I'd put it right after the MX records, since they're related

I was kind of guessing that this is the type of data you had in mind when I asked if DNS was what you were actually talking about. DNS stands for Domain Name Server and used to translate your typed in URL to an IP address, nothing more. The MX records you're referencing are only seen when you do a DIG type operation, which gets you back a whole passle of information. And the catch there is that although you would think that the data contents found in these records would be standardized, they aren't, so there'd be a heck of an issue trying to weed through all the contents of that data response with the hopes that the one line you're looking for is there and in the right format. That so much of the current WHOIS data is screwed up, bad addresses, old data, alternat language / character set content, etc., suggests that adding more "suggested required" fields would probably be a losing battle <g> For example, there isn't even a commom standard for Postmaster, some using Hostmaster for whatever reason.

no different than MTA's adding the ability to check against an RBL

Again, much different as checking an RBL is an external process, vice your original suggestion of adding bits to a DNS transaction.

IP of SMTP server doesn't match the domain? Forward to /dev/null

Actually, this can be done right now. However, complicated by some local configurations, some close upstream configurations, so which IP do you select as the "source" IP of the e-mail to make the decision against? (Pretty much the same issues that the SpamCop parsing tool tries to deal with) Not to mention the performance hit that this e-mail server would have to cope with.

Link to comment
Share on other sites

DNS stands for Domain Name Server and used to translate your typed in URL to an IP address, nothing more. The MX records you're referencing are only seen when you do a DIG type operation

Well, I just know I put them in my zone files for DNS ;-) As all mail servers had to find this anyhow, I figured it wouldn't be too hard to look for another record type. Apparently I was mistaken. As far as determining which IP to check for, wouldn't the connecting IP always be the IP to look up? If I send mail from foo.com to foobar.com, doesn't foo.com's SMTP server always talk to foobar.com's MX server? Or am I simplifying the SMTP process too greatly?

Link to comment
Share on other sites

doesn't foo.com's SMTP server always talk to foobar.com's MX server

Yes, that's true. But the flip side is .... is the SMTP transaction actually an e-mail from someone at foobar trying to contact someone at foo? Or has foobar been compromised? In this case, checking that IP doesn't do anything at all for spam control. And in a couple of current Topics right here on this Forum Board, we have some folks that claim that all they do is Forward e-mail to / from others, so allegedly, their records could be tagged as good, per your suggested mode, but their IP wouldn't mean squat as far as where the e-mail / spam actually came from.

As all mail servers had to find this anyhow

Not really. In general, you've got an e-mail server sitting there, just listening to the outside world, waiting for someone to come knocking on it's door, and upon answering siad knock, does the entity know the methods of negotiating a handshake to be able to then drop its package? So there's not normally a DNS process involved at all, only the negotiation of hooking up and exchanging the data packets. Outgoing e-mail will do the DNS look-up, but this doesn't have anything to do with your suggested additonal look-up, as this is the Sender doing the check.

Link to comment
Share on other sites

Yes, that's true. But the flip side is ....

Not sure I entirely understand what you were trying to say, but I'll guess at it :-)

Let's say we have the following conversation where a foo.com user sends a message to a foobar.com user:

foo.com user -> foo.com SMTP -> foobar.com MX -> foobar.com user

This would be good, since the foo.com SMTP should have a correctly configured SPF record for itself, and at foo.com, that admin should only be allowing his own users to send mail.

Now, if we had a foobar.com user trying to send through the foo.com SMTP server...

foobar.com user -> foo.com SMTP -> *Transaction Halted*

... it should be blocked since the foo.com SMTP server shouldn't be accepting mail from a foobar.com IP... unless as you mentioned, they're compromised, and then again it's an admin with bigger problems than spam prevention. In the meantime, you could block their domain.

Outgoing e-mail will do the DNS look-up, but this doesn't have anything to do with your suggested additonal look-up, as this is the Sender doing the check

Ahh yes, I muddled up my SMTP and MX thoughts there. However, I know you can tell an MX server not to accept mail without valid rDNS, so the functionality to make a DNS lookup with an MX server is still there.

Link to comment
Share on other sites

I can't find it now, but there was somebody who was trying to set up a system where the sending server would have know the correct "handshake" for a receiving server to accept email. Since I am not technically fluent with email systems, I am not quite sure what the protocol was.

IME, anything that requires major re-alignment of existing protocol is seen as not practical by the ones who run the servers. Blocklists do just fine in most cases particularly backed up by content filters and whitelists.

My vision is that bulk email *has* to be identified by a header line (already an RFC). Any email that is identified by reporting (and two reports make a bulk email) that does not have the header line goes on a bl. ISP's will have to beef up measures to make sure that nobody sends bulk email without being legitimate in order to keep from being blocked. Of course, if it works the spammers will also put the header line in. Then there will be an additional step to confirming that you want bulk email - you have to whitelist it. Otherwise all bulk email is blocked by your request. But no "individual" email is block. Thus, there is no problem about getting email from unknown individuals who might want to email you. If that becomes a problem, then measures will have to be taken. But it would be very labor intensive for the spammers. There is nothing in the plan that isn't already being used except the bl which would have to be designed.

But it would require major re-education and nobody wants to do it.

Miss Betsy

Link to comment
Share on other sites

  • 2 weeks later...
Now, if we had a foobar.com user trying to send through the foo.com SMTP server...

foobar.com user -> foo.com SMTP -> *Transaction Halted*

... it should be blocked since the foo.com SMTP server shouldn't be accepting mail from a foobar.com IP... unless as you mentioned, they're compromised, and then again it's an admin with bigger problems than spam prevention. In the meantime, you could block their domain.

A foobar.com user that is on a foo.com I.P. address should be able to send through the foo.com mail server. There is nothing wrong with that.

A foo.com mail server should not accept e-mail from I.P. addresses it does not trust, or if it does not trust the I.P. address it should use SMTP auth.

All the SPF systems do is increase the cost and complexity of sending e-mail, but do nothing at all to prevent a compromised computer from using the certificates or other registration to send spam, particularly through the ISP's mail server.

Right now, RFCs require that a mail server have a valid rDNS (reverse DNS) entry.

That means that if a mail server at 10.0.1.200 connects to a mail server and says that it is mail.example.com, I hould be able to look up the hostname for 10.0.1.200 in an DNS, and it will come up with mail.example.com as one of the names returned.

Estimates on the various forums are that small but significant set of real mail servers are failing this test, and not enough big networks are requiring this to put pressure on the remaining ones to fix their configuration. And some of those big networks have mail servers that have bad rDNS.

Estimates are that 80% of spam will fail an rDNS check.

Now spammers can adjust their spam to pass an rDNS check, so this is not fool proof.

The fact though that rDNS could easily be used for a fast reduction in spam, and can not be because of known misconfigurations, indicates that it would be even harder to introduce more complex changes.

One of the proposed changes that would wipe out a lot of spam through compromised machines is an rMX record. Right now MX records are for incoming mail, and rDNS is required for outgoing mail (not enforced).

With rMX, the sending mail server would be required to have an rMX record. An ISP would not have to coordinate with any standard body to self certify.

And even that is not really needed. All network providers have to do is block port 25 outgoing for any I.P. address that is not authorized to run a mail server.

If someone needs to access an external mail server, there are alternate ports desingated by RFC to be used.

So in short:

a network can easily and economically turn off spam that does not come through their registered mail servers, they just choose not to and pass the extra costs for congestion overloads, abuse handling, and bandwidth on to their customers.

And a certificate system does not accomplish anything that an network provider could not do now, but at a lot less cost.

And other networks could insist that networks take the steps now to prevent e-mail from other mail servers, yet with rare exceptions they do not.

All of this can be done now, with the current SMTP and network technology.

All it takes is a significant number of mail server operators taking the attiude that if a network allows spam to come from any thing other than one of their main mail servers, that mail from the entire network will be unconditionally rejected.

That does not fix multi-hop spam, but the ISPs seem to care about stopping spam from real mail servers.

-John

Personal Opinion Only

Link to comment
Share on other sites

I'd put it right after the MX records, since they're related

I was kind of guessing that this is the type of data you had in mind when I asked if DNS was what you were actually talking about. DNS stands for Domain Name Server and used to translate your typed in URL to an IP address, nothing more. The MX records you're referencing are only seen when you do a DIG type operation, which gets you back a whole passle of information. And the catch there is that although you would think that the data contents found in these records would be standardized, they aren't,

I have to disagree with you.

DNS records are highly standardised, and a SPF record could be created, if IANA were to assign an RR TYPE code to it. I think you are confusing the view your tools give you with what really happens. (ie nslookup gives you an ip address for a name, and then theres dig which gives you a whole lot more stuff)

The main probem is that legitimate mail doesn't just come from the server of the ISP that has the domain. If you have an email forward set up, mail is resent from the server that is doing the forwarding, so mail from bill[at]msn.com would reach me[at]vanity.com, this server would try to forward mail to customer15322[at]isp.com, which would look up the SPF record for msn.com and drop the mail as spam coming from an unauthorised host.

similarly when you send mail to a mailing list the server sends it out as if it came from you to everybody subscribed to the list. this would not reach you if your recieving server was SPF aware.

Some web sites send email on your behalf - greetings cards, send this page to a friend, - and while I would slap anyone who passed the email address I gave them to communicate with me i recognise this as legitimate.

Link to comment
Share on other sites

MX records ... although you would think that the data contents found in these records would be standardized, they aren't

Yes, they are. Please see RFC 974: Mail Routing and the Domain System (part of Internet Standard 10), RFC 1035: Domain Names - Implementation and Specification (Sections 3.1, 3.3, and 3.3.9 as annotated here; part of Internet Standard 13) and RFC 3330: Special-Use IPv4 Addresses (Sections 2 and 3 as annotated here; Informational) for details and bogusmx.rfc-ignorant.org listing policy for an RHSBL that pays strict attention to them.

Link to comment
Share on other sites

Sorry .. yes there are RFC's and standards ...  however, in the real world .....

People don't care about the revese lookup and HELO matching because it gains nothing.

If it were used by most people to validate messages the spammers would fix it, rather than faking it in order to confuse novices trying to work out where the spam came from.

Personally I think name in HELO should be phased out, it made sense for RFC788 as you possibly didn't have the calling parties address in your host.txt file (this was pre-dns) and it made your logs nicer, nowadays it's only there for human consumption, and only humans get misdirected by spammers using it to lie

rfc2821 says you shouldn't block it because it doesn't match. there are some legitimate situations where the sending server doesn't know its presented IP address.

in short: use this as a test in part of a weighted system, but don't treat it as black and white.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...