Firstly, you must own a domain name. If you don't have a domain name and you're sending email using someone else's domain name, you need to contact the adminstrator for the domain you are using.
Let's assume you have a domain name, you're running your own mail server, and a dynamic IP number assigned by your ISP. To make this work, you're already publishing DNS records for your domain that get updated every time your IP number changes. If your server transmits your mail, SPF is much easier than what you're already forced to do... just publish "v=spf1 mx -all", meaning that all messages come from your server.
Suppose you're not really running your own server. Maybe someone else receives for you and forwards the messages. This is common with "vanity domains" (a name specific to you). Maybe when you transmit, you relay through your ISP. In that case, you could use the "include" type if your ISP publishes a SPF record, or if you know the IPs of their servers you could specify their IP number, or if you only know the netblock assigned to your ISP, you could "ip4" with a mask for all your ISP's IP range.
Or maybe you transmit directly from your dynamic IP number without relaying through your ISP. Again, SPF can handle that too... as long as you know the range of IPs your ISP uses to assign for you. Just use the "ip4" type with a mask (or mulitple "ip4" if you ISP assigns from more than one pool of IP numbers).
Whatever you do, you can specify additional methods to cover the other possible cases, so that your messages won't get rejected.
Every spam article, someone posts an opinion that if everyone would just use crypto (usually PGP is suggested), all these problems would be solved. After all, strong cryptographic authentication proves the message is from a legitimate sender, so the arguement usually goes, so the relatively weak authentication offered by SPF / Caller-ID / Sender-ID is only sub-standard.
For a moment, neglect the high costs, complexity, worldwide legality and PKI problems of crypto, which are all solvable at some cost. They aren't the fundamental problem.
Strong authetication answers the question:
Is this message almost certainly authentic?
That's a very nice to know if you need to place a high level of trust in the message, such as correspondance from your bank. Today email is virually worthless (in the absence of PGP) for trusted messages.
Saddly, the answer to this question is not valuable for filtering out junk. The question that needs to be answered instead is:
Is this message almost certainly forged?
PGP does not answer this question. Neither does Yahoo's DomainKeys. There are many circumstances where the signature can not be verified. You can not use the failure to verify a PGP signature as a reliable means to filter out junk.
SPF and MS Caller ID are designed to answer this second question reliably enough to discard forged messages. They answer this question for all domains that publish SPF records (aol.com, gmail.com, etc) regardless of whether SPF is widely adopted by the rest of the world.
When the claimed domain published a list of designated senders, and the sending MTA's IP number isn't among them, you can be certain the message is a forgey and discard it (or close the connection before the data phase, saving bandwidth).
PGP and other crypto signature schemes simply do not deliver this ability to detect forgey. They only detect authenticity.
the recipient checks that the sender has authoritiy to send out email for the domain.....
Yep, that's right
So, we all have to set up SPF records for our domains or our emails will get rejected by some ISPs. Is my understanding right?
Nope, that's wrong.
Messages only get rejected when a SPF does exist for the claimed domain and the MTA transmitting the message is not a valid sender for the claimed domain. Messages are NOT rejected simply because the claimed domain fails to publish a SPF record.
If you do not publish a SPF record, no messages claiming to be from your domain get rejected. This is true today, and it is likely to remain true even after SPF is widely deployed.
Of course, if you have a domain name, it is certainly in your best interest to publish a SPF record. Well, that is if your all email transmits from certain servers or one of the many other very flexible ways SPF's syntax can specify. Publishing a SPF record is the only way you can cause SPF-aware receivers to reject messages that claim to be from your domain, but are actually forged by spammers, virus programs, phishing scammers, and so on.
In the real world this doesn't happen. Deadlines slip, and if they slip to far management and / or devs have to decide what are the most important things to fix.
Sometimes this means an obscure URL parsing bug will allow phising scammers to make the browser display a URL of their choosing, thereby accurately impersonating credible banking websites and thousands of unsuspecting end users will fall victim to identify theft scams because their browser confirmed they were sending their sensitive info to their bank.
Sometimes it means memory will still be used after being freed, allows conditions that open the door for remote access with full administrative privs, resulting in hackers breaking into major sites and stealing massive lists of sensitive information, including thousands of customer credit card numbers.
Sometimes this means applications don't handle network data properly and buffers overrun in a database server that most people don't even realize they have installed, providing a mechanism for the fastest spreading internet worm of all time to greatly disrupt most internet traffic and effectively take down ATMs and lots of other important machines.
Sometimes it means poor design decisions emphasize ease of use at all costs, providing unskilled masses of users with a mechanism to accidentally execute malicious code attached to an email, with virtually nothing visually or otherwise distinguishing this dangerous (and detectable) circumstance from the ordinary way they conduct their jobs and exchance information with friends using email attachments that are not potentially dangerous.
Saddly, in the "real world", the choices Microsoft has made have clearly lead to much more harm than incomplete documentation, spelling errors, unavailable spellchecking and crashes in rare circumstances.
Whatever's in all those D-Link routers... you know, the ones that expose their configuation ability to the outside world with a master override password that can't be changed or turned off.
crashes more frequently
MacOS 6 through 9 (well, nothing can hold a candle to Win 3.1 for tendancy to crash, but certainly Apple has a much longer legacy of "one app takes the whole system down")
EULA more restrictive
Unix
slipped the scheduled release date more often and by a larger margin
What happens if there's a management turnover at Novel and the new guys in charge decide to take up the SCO litigation business model only with the added benefit that these decisions show they own the copyrights?
To prevail in a copyright infringement suit, you need to prove two things:
You own the copyright
The copyrighted material was copied or distributed by the defendant
SCO's having trouble on both. Fail either one and they lose.
Proving #2 is going to be nearly impossible for anyone in the future if IBM wins summary judgement or judgement at trial on their 10th counterclaim. Likewise, if Redhat wins.
Attempting to sue before these are decided may allow scumbags to spread a lot of hype, but any such case would probably be stayed until the IBM and Redhat cases are settled.
Yeah, it sucks, but it's certainly nothing new. Poor public policy that caters to industry is nothing new.
This outrageous intervention by industry had never been done on a matter of public health before.
Can you say "The Four Food Groups"? Knew ya could.
I'm sure there are plenty of great examples before 1950's, when the 4 food groups "public education" was written to cater to the politically important food producers, expecially the meat and dairy farmers. It's only been in the last 10 years or so that the myth of the 4 food groups has been replaced with the "food pyramid", despite decades of studies showing the emphasis on meet and diary to be unsound.
Here's an article about the numerous problems with the 4 food groups, and here's a quote from it:
When Congress created it in 1862, the USDA was charged with educating the public on agricultural matters, including food policy, while working with food producers to provide a reliable, consistent food supply. The agency published its first food guide in 1916, and it was designed largely to encourage diets based on foods produced by those with the most clout. In the early '50s, the USDA created four basic food groups: milk, meat, fruits and vegetables, and breads and cereals. Food industry representatives like cattlemen and dairy farmers were integral to this process.
During the '70s, studies revealed the health dangers of fatty foods, and a Senate committee suggested the basic four food groups be revised to reduce the intake of cholesterol and saturated fat and increase the consumption of fruits, grains and vegetables. But outrage from influential groups of food producers forced a revision of the report from a message of "eat less meat and milk" to "choose lean meat and nonfat milk." In 1991, the USDA attempted to release an "Eating Right Pyramid," which emphasized grains and vegetables rather than animal products. But, according to the PCRM, "the Cattlemen's Association joined forces with the National Milk Producers Federation and other trade associations in opposing publication of this new model. Within weeks the Eating Right Pyramid was withdrawn."
The continuing influence of food producers in designing the USDA's dietary guidelines has prompted a lawsuit from the PCRM against the USDA and the Department of Health and Human Services (DHHS), another federal agency involved in setting the dietary guidelines. The suit alleges racial bias and conflict of interest in the formulation of the guidelines and the food pyramid. American minorities are disproportionately affected by chronic diseases, the suit charges, and would be better served by dietary guidelines more inclusive of their needs.
The group claims that those concerns are missing because six of the 11 advisory committee members who devise the guidelines have explicit links to the meat or dairy industries. Specifically, the PCRM charges, the committee chairman and at least five other committee members have had links to the National Dairy Board, the National Dairy Council, the American Egg Board, the National Cattlemen's Beef Association, the American Meat Institute, the Dannon Research Institute and other similar groups.
"Having them on the very panel that is supposed to decide what's healthy for Americans to eat is like having Joe Camel on a committee designed to help people quit smoking," said PCRM president Neal D. Barnard when he announced the suit. While all Americans are ill-served by these questionable guidelines, Barnard noted, the problems are magnified in groups that are hardest hit by chronic, diet-related diseases.
So if they need an equivalent amount of memory....
Saddly, they do NOT need equivilant amounts of memory.
A modern Linux desktop needs MORE. A LOT MORE.
My girlfriend's machine has Win2K and usually runs Mozilla (mail and web), Quickbooks, UPS Wordship, Excel and Word 2000, iTunes and a half dozen little applets. IE is probably always taking up memory, as we've done nothing to disable or remove it. 512 megabytes of RAM seems to be fine.
My machine has Linux (roughly redhat9, kernel 2.4.20) and usually runs Mozilla, Openoffice, vmware (64 megs for an old win95 app), Nvidia's drivers, about 5-10 terminals, the gimp, a few vim sessions in them, gcc and other tools occasionally, some instances of xpdf, and usually a couple terminal emulators talking to hardware I'm developing. With only 512 megs, if I get a lot of stuff open, the system slows to a crawl. I recently bumped up to 1 gig of RAM and it runs well.
what they can learn from the IBM source code can be applied to SCO's own software products.
No.
First, it's under a protective order from the court. If they violate that, IBM will sue and destroy them... hopefully sooner with a temporary injunction rather than later with an ultimate verdict.
Second, much of the code was disclosed only to SCO's attorneys and not directly to SCO. See the complains from Computer Associates.
Third, SCO's unixware and openserver business is dying. Few (if any) new installations are being made. Even if they made dramatic improvements, those products are about as good as dead in the market due to a long history of neglect.
Fourth, their reputation is ruined. Nobody in their right mind will trust SCO now. And why should they, when "solutions" are readily available from large, stable companies with good reputations.... like IBM.
Fifth, they've already cut back (laid off employees), so their capability to illegally integrate lots of AIX code is reduced... and as things get worse for SCO this problem will only increase.
And finally, they will run out of cash soon anyway, with 4 lawsuits against corp heavyweights rapidly draining their funds. Their chances for further investment are slim, after the high profile Baystar dispute. Their stock has fallen enough that their ability to raise funds by issuing more shares is diminished, and if Kimball grants IBM even one bit of the summary judgement or makes a negative (for SCO) opinion in the Novell case, their stock valuation will be dropped back down to the sub $1/share where it rightly belongs.
Only a miracle is going to save SCO now... like Kimball buying their expansive theory of derivitive works, or suddenly finding a lot of directly copied SysV (not AIX) code inside of Linux.
As the ancient saying goes: "If you play with a snake, you get bit."
I really like Sun, but this serves them right after paying SCO...
Are you suggesting that many years ago, when AT&T (USL) owned unix and no PC based OS was able to function as a server or do serious business work (eg, DOS 6 and Win 3.1 at the time), that Sun should have forseen that Unix code they licensed would eventually be sold to Novell, and then to old SCO, then various Calderas, and then Caldera would rename to SCO and finally replace its management with slimey bottom feeders who would attempt to be annoying to be bought out by IBM, and then failing that launch a rediculous shake-down scheme?
I jaw dropped when I caught this little gem of honesty among all the deception, spin, and half truths:
To write Samizdat, I worked with (and quoted) many individuals directly or indirectly familiar with Linux development. AdTI will continue to interview people within the open source profession about open source.
It would be skewed and bias to only quote people that are anti-Linux or anti-open source. I have done this for years, and will continue to do so, regardless of what a source thinks of my theories.
At least we'll have a whole week of major open source / free software figures publishing rebuttals.
One thing is pretty clear. Tanenbaum has dealt a blow to their credibility, enough to attack him rather than be quiet and avoid drawing more attention to their critics. That's a good sign that exposing ADTI/Brown for the deceptive corp whoring spin doctors they are is hurting them.
With any luck, next week's rebuttals will circulate widely and further drive ADTI's reputation down. The more ADTI suffers from this, the better it will deter other "research groups" from taking Microsoft's money to publish lies and deceptive spin.
Apart from the many advantages others have mentioned, in the long run the cost will be lower.
But what's the point of 1x slots? Plain PCI works just fine.
ISA and VLB worked just fine too.
A 1x PCIe slot is 250 Mbyte/sec (dedicated bandwitdh in both directions), whereas plain old 32 bit 33 MHz PCI is 133 Mbyte/sec (shared half-duplex amoung all slots on the same bus).
I'm assuming we will see boards with more than one 16x slot at some point
Probably not in the consumer realm.
Perhaps on servers... the segment of the market that today usually has 2 or 4 Opteron or Xeon CPUs and several PCI-X (64 bit, 133 MHz) slots.
Consider that a 4x PCIe slot is 1 Gbyte/sec (in both directions, dedicated bandwidth not shared with any other slots). That's fast enough for 10 Gbit/sec ethernet! Or a RAID0 array of TWENTY high speed drives (assuming a platter/spindle speed of 50 Mbyte/sec).
Yes, the damage has been done. But complaining loudly does accomplish something useful... ruin ADTI's reputation.
The more pain this causes ADTI, the lower their future credibility sinks, the number of people whose long-term memories record ADTI as the bunch of corporate whores they are... the more damage is done to their prospects of seeking future funding. Even from Microsoft, it won't make sense to pour more money into ADTI if they are widely considered a joke.
Better yet, if ADTI suffers, the public scandal will help deter other "think tanks" from attacking free software when Microsoft or other proprietary vendors come knocking with "research" dollars.
if mail clients were configured to start using PGP (GPG) keys and signatures by default.
If you reject messages without a PGP signature, spammers will simply sign their messages.
If you reject based on the signing author being a known spammer, spammers will simply generate a new key for each message. This isn't a computational burden (as it is in PGP) if the keys aren't generated in a secure manner.
If you reject all unknown senders, people unknown in your "web of trust" will be rejected.
instruct unknown senders (people who aren't in my contact list yet) to download my public key from a specified location to encryp a message that would bypass my filtes.
These challenge-response systems are already in use today, by people willing to be rude to previously unknown senders. They suffer from all sorts of problems (out-of-office autoresponders, automatically generated shipping notices for online purchases, and other legitimate automated senders). How is adding the complexity of PGP an improvement?
The original statement is missing one important word "if [all] mail clients were configured".
This is an idea that just won't work if any significant number of senders still send out plain, old email as they currently do.
Contract with SPF and MS's Caller-ID, which are effective at detecting forgey when only the (claimed) sender publishes a SPF and/or Caller-ID DNS record and the receipient checks it.
To be successful, an change needs to provide value for those who have implemented it, even before widespread adoption occurs. SPF and MS Caller ID meet this goal, as people checking SPF and Caller ID can already reject forgeries claiming to be among 14000-some domain names (including AOL and Hotmail), and domain name admins who publish their SPF and/or Caller ID records are already receiving some protection from having their names forged.
The scheme "let's all switch to PGP" doesn't allow receivers to filter out messages until almost all legit senders sign their messages, and senders who sign their messages don't get much value from the signature until almost all receivers reject unsigned messages. Even then, PGP still suffers from the problem of unknown signatures, requiring a massive worldwide trust database or all the problems of callenge-response negotiation for new contacts.
PGP is an excellent answer to protecting privacy and proving strong authentication. Saddly, crypto only answers the question "is this message certainly authentic", but the question that needs answering is instead "is this message almost certainly a forgery".
The plan is to support both types of records as soon as possible. The "flag day" is not about...
Before the flag day, SPF will work the way it is now. After the flag day, which will probably occur later rather than sooner, SPF will have all the functionality of Caller ID.
Here's a
line
to the post with the real info. Feel free to re-read it. Here's the sections about the "flag day". It's easy to see the "flag day" is about requiring forwarding MTAs to implement an extension to ESMTP, not the dual syntax of accepting either v=spf1 or xml (which will presumably occur very soon, since it doesn't impact anybody negatively, except people with a religious believe that one syntax ought to be universal.)
THE BIG NEW IDEA: let's define a new ESMTP field, "RFROM".
[snip]
If a MAIL RFROM is not present, checks run against the PRD from the headers...
... Until the Flag Day, when you can go back to checking MAIL FROM if the RFROM is not present.
[snip]
THE NEED FOR A FLAG DAY
* The promise made to the SPF camp was: you will one day be able to reject forged MAIL FROM based on SPF lookups. I intend to keep that promise.
* Under the Old SPF, until the forwarders were all SRS compliant, we used a hacky workaround with trusted-forwarder.org.
* Under the New SPF, until the forwarders all use RFROM, we are in the same boat.
* Either way we need the industry to announce a flag day: we need to strike a balance between giving forwarders lots of notice, and being able to block stuff before DATA.
* Changing the burden to RFROM instead of SRS makes things a lot easier for forwarders. That reduces their adoption threshhold. Everybody wins.
* We can't decide today when the flag day will be, but one day soon we probably will be able to.
* Before the Flag Day:
- Campaign for MTAs to start supporting RFROM.
- In the absence of RFROM, receivers SHOULD NOT reject spoofs until after seeing data, and SHOULD use responsible addr from 2822 header.
- (Receivers who know exactly who's forwarding to them may choose to reject anyway. Local policy, etc.)
- Fight Joe Jobs with SES.
* After the Flag Day:
- MAIL FROM RFROM now expected from forwarders.
- MAIL FROM spoofs without RFROM MAY be rejected.
- Flag day requires industry coordination to ensure MAIL FROM / RFROM support is out there.
- RFROM harder to spoof because only a PASS result is acceptable.
SPF doesn't block spam unless the mail system makes it mandatory, after all, so until 100% compliance is reached, non-SPF mail will still have to be accepted.
I'll type out an example, to show you exactly how it is already working and rejecting forgeries TODAY, without being mandatory, and long before widespread implementation.
Suppose your MTA receives a message from a spammer who is impersonating me. The message claims to be from "paul@pjrc.com", but it isn't. Your SPF-aware MTA (or spam filter) does a TXT query to my domain, and because my domain is one of the 14500-some returning SPF, you'll get this:
pjrc.com text "v=spf1 a:outgoing.pjrc.com mx -all"
That means there's only two sources that are authorized to send messages for pjrc.com. So your software will first do a lookup on "outgoing.pjrc.com", sorta like this:
If the IP number of the MTA sending the message is 168.143.160.91, then you know the message is coming from my server. If not, then the next authorized source is checked. Your software will do a MX lookup, like this:
If the MTA sending the message has the IP number 168.143.173.65, then you also know the message came from an authorized server for my domain, and thus the message is not a forgery by a spammer.
However, the last part of the SPF record was "-all", which means NO OTHER sources are authorized to send pjrc.com's email. So if the MTA sending the message is any IP number other than 168.143.160.91 or 168.143.173.65, then you know it's being sent from an authorized source, and thus it's a forgery (or I've messed up my SPF record).
Please take notice that for this to work, only you and I need to have SPF implemented. All the communication was between your receiving MTA (or SPF-aware spam filter), and my the DNS server for my domain. No other servers or other hosts on the internet needed to implement SPF in order for you to discover that a forged message isn't really from me.
Of course, only about 14500-some domains are currently publishing SPF records... so you can only detect forgeries if the spammer is foolish enough to forge one of our domain names. However, "aol.com", a very commonly forged name, is on the list. Likewise, "hotmal.com" is publishing caller ID (which works more or less the same as SPF, but with different syntax and with the minor distinction of sender vs from).
The bottom line is that your statement is incorrect. SPF does not have to be mandatory to function. It already works for those cases where the receiver bothers to check and the (claimed) sender publishes a SPF record. You can already reject all forgeries from 14500-some domains, including little ones like mine and big ones like AOL and Hotmail... and this is fully functional TODAY, long before 100% compliance is reached.
Really, the existing e-mail header is the same as caller ID.
Really? How, exactly, are existing email headers anything like a DNS server that answers a query with a list of IP numbers that are the only ones authorized to transmit email for that domain?
In theory it says who's calling, but anyone dedicated can get around it.
Microsoft's Caller ID (and SPF) are about providing a DNS-based query that can be used to check if the IP number of the system sending the message is among the servers that are supposed to be sending that domain's email. Well, that's a bit over-simplified, but still the basic idea.
Caller ID and SPF aren't about adding an easily faked extra bit of info to the email headers. The IP number of the sending MTA is not easily faked, because SMTP uses TCP/IP which requires round-trip packet exchange, and the receiving MTA adds the "Received" line to the header with the verified IP number of the other MTA that sent the message.
To "get around it", a spammer who's forging someone else's domain name would have to be able to intercept or interfere with the receiver's DNS query. Very unlikely... especially when using open proxies, hacked home-user machines, free trial accounts, and anything else that's in no position to interfere with the receipient's DNS.
Of course, a spammer can also "get around it" by using a domain name that is under their control, and simply return a Caller ID or SPF result that says the IP number they are using is authorized (or that all IP numbers are authorized). This is what spammers will do (and reportedly some are already doing). But forcing spammers to use their own domain names is the goal of domain-name authentication.
Why don't they just call it like it is?
"Caller ID" in voice phone systems refers to the transmission of caller identify between the first and second ring. It seems you have assumed Microsoft's email Caller ID works roughly the same way, but it does not. The sender's IP number is always known (and virtually impossible to forge) because of the mechanics of TCP/IP, and Microsoft's Caller ID proposal is a query to the claimed source for a confirmation that the IP number is among the ones that are authorized to be sending.
A secure substitute for the "source" field of the e-mail header.
You completely misunderstood how it works. Hopefully you now understand.
The plan appears to be to support both XML and v=spf1 formats (according to the summary of the meeting between the SPF and Microsoft folkw). The expectation is that the vast majority of sites will publish the simple and compact v=spf1 format for the forseeable future. XML allows extensibility for the unforseen future that follows afterwards.
Crypto-based signatures are really good at answering the question "is this message truely from the claimed sender?" That's nice to know for many applications, like on-line banking, submitting payment information to a merchant, and so on. Saddly, the answer to that question isn't very useful for filtering out spam and other junk.
The important question is "is this message almost certainly forged". Signature checking can tell if that is _might_ be forged (the signature was missing or didn't match)... but unless you're among a very small minority of anti-spam activists, what you definately don't want is a "false positive" that accidentally filters out legitimate messages.
For crypto to be useful in filtering out junk, many things all have to work perfectly. You have to be absolutely certain that the claimed sender transmits ALL outgoing messages with valid signatures (high cost to implement, especially for large organizations with many servers). The signed portion of the message must not be modified by buggy servers or communications. You have to be able to get the public key. The sender has to manage their keys properly (keep expired ones around for delayed checks, keep the private key secret, properly update them as needed, and so on). If any of these things are less than highly reliable, the result is the signature does not match on an otherwise valid message.
Spammers are just going to use a DNS server to tie the domain to the IP.
The registrars are going to love that, since domain blacklists will quickly list any new domain they register and use to spam.
Even at volume domain name pricing, it's going to add considerable expense and difficulty for spammers to constantly buy new domain names names... or reuse ones already on blacklists.
Of course, whitelists will also probably develop in response to widespread adoption of domain name authentication.
If a system is compromised (i/e: with a virus/worm) couldn't the technology be defeated via that as well?
I believe it could. If an attacker compromises any server with an outgoing MTA, they can probably get the private key. Maybe the on-disk copy will be encrypted, but I'd guess most admins won't want to have to type a passphrase every time the MTA needs to be restarted.
Signing messages like that sounds like a good idea
As I posted earlier, it sounds like a good idea, but I suspect it won't be really useful.... and not because of unrelated security weakness on servers.
DomainKeys can do a very good job of determining what a message is authentic. How useful is that? Here's two different questions you could ask about a message:
Is this message definately authentic?
Is this message almost certainly a forgery?
Being able to answer question #1 might be nice, but the answer to question #2 is that's useful for filtering out spam, virus messages, phishing scams, and so on.
To answer #2, first the legit sender domain needs to implement an outgoing signing policy of all messages signed. So ALL MTAs have to be updated to new code (as well as the policy and key(s) published by DNS). Without that policy and all MTAs correctly upgraded, all a spammer has to do is not include a signature at all (exactly what they do today), and the answer to both questions will be "No". Until you can answer "Yes" to question #2, you're doomed to see that spam and manually delete it (well, unless SPF or some conventional or bayesian filtering rules catch it).
You seem to be saying that SPF is junk because it couldn't support forwarding for "some users". Perhaps you were aware that you neede to add SRS to your MTA to support this, and your opinion that SPF is junk is based on an unwillingness to make any changes to your MTA (admittedly, sendmail is such a pain I try not to touch it if everything's working and no security update is needed).
In that case, I wonder what your opinion of DomainKeys will be, with its requirement (on top of a DNS record as in SPF) to modify your MTA to sign all outgoing message so that any users can use it.
Or maybe you were unaware of SRS... and perhaps also unaware that implementing DomainKeys requires not only the easy task of publishing a public key by DNS (which is all that SPF requires for most users), but also adding code to your MTA to sign the outgoing messages with your private key.
I just don't understand how DomainKeys is going to be useful in filtering out junk. Maybe I missed something? Before you hit "reply" to say it uses strong crypto and therefore must be good, read the IEFT draft and my impression after (quickly) reading it myself.
In section 3.7.1, domainkeys is supposed to either "verify" or "fail to verify" the message. To be useful in identifying spam, virus/worm messages, phishing scams and other junk, these two outcomes by correlate well with whether the message is desirable or junk. Or at the very least, at least one output must have a very low correlation with legitimate messages, because only the most agressive anti-spam advocates are willing to tollerate "false positives" (accidentally mistaking legit messages for spam)
Saddly, reading the rest of section 3.7 (and scanning most of the draft quickly), I'm seeing what looks like a lot of design that will cause "verify" to be a very strong indication that the message is good, but "fail to verify" seems like to correlate with spam/virus/scam, domainkeys not implemented, and a variety of configuration problems (not like computers would ever be configured incorrectly....)
I believe this binary output clause in section 3.7.1 doesn't match up well to the real world, where at least three board categories are likely:
Signature verifies the message with the claimed sender's key.
Claimed sender domain does not implement DomainKeys (or claims a policy where some messages are sent without signatures) or claimed sender configuration problem
Signature missing (claimed sender has policy of inclusion on all messages) or signature does not match.
Most people will only want messages rejected or filtered in condition #3, but accept then in #1 and #2. I strongly disagree with this conclusion from section 3.8:
A client can normally just look for "good" and can safely assume that
all other values imply that the verification failed in some way.
Until DomainKeys it very widely deployed, condition #2 will be the norm.
Worse yet, it seems unlikely many large, well-known domain names (the ones spammers spoof the most) would select an outbound signing policy (section 3.6.2) indicating all outgoing messages are signed... at least until they've made sure ALL their MTA are upgraded and running DomainKeys flawlessly.
Saddly, it appears that the DomainKeys binary output of section 3.7.1 returns "verify" only on condition #1, and "fail to verify" in conditions #2 and #3. To be useful, especially in a gradual adoption phase, what is needed is a good indication of condition #3... when a message is most certainly junk and should be deleted.
If DomainKeys section 3.7.1 were rewritten for a 3 state output, and perhaps section 3.7.5 were replaced with something less vauge, and a more realistic way to act upon the results (section 3.8) is suggested... then DomainKeys would probably be as effective as SPF and MS's CallerID, but with the cost of only reworking transmission on forwarding MTAs to reworking transmission on all MTAs.
Or maybe I misunderstood something from the draft, or missed some part? Maybe someone will reply and explain why my pessimistic view of DomainKeys is misplaced?
BTW: full-disclosure, my domain is one of the 14500-some that is currently publishing a SPF record. I'll probably publish a MS CallerId record if the patent issues are cleared up, and if DomainKeys takes off, I'll probably add whatever patch signs outgoing messages too.
Slashdot Mirror
Yes, it is very flexible, with many other alternatives.
like digital signing with a hidden key whose pair is regestered in the DNS?
This isn't an option, but there are many alternatives.
Firstly, you must own a domain name. If you don't have a domain name and you're sending email using someone else's domain name, you need to contact the adminstrator for the domain you are using.
Let's assume you have a domain name, you're running your own mail server, and a dynamic IP number assigned by your ISP. To make this work, you're already publishing DNS records for your domain that get updated every time your IP number changes. If your server transmits your mail, SPF is much easier than what you're already forced to do... just publish "v=spf1 mx -all", meaning that all messages come from your server.
Suppose you're not really running your own server. Maybe someone else receives for you and forwards the messages. This is common with "vanity domains" (a name specific to you). Maybe when you transmit, you relay through your ISP. In that case, you could use the "include" type if your ISP publishes a SPF record, or if you know the IPs of their servers you could specify their IP number, or if you only know the netblock assigned to your ISP, you could "ip4" with a mask for all your ISP's IP range.
Or maybe you transmit directly from your dynamic IP number without relaying through your ISP. Again, SPF can handle that too... as long as you know the range of IPs your ISP uses to assign for you. Just use the "ip4" type with a mask (or mulitple "ip4" if you ISP assigns from more than one pool of IP numbers).
Whatever you do, you can specify additional methods to cover the other possible cases, so that your messages won't get rejected.
For a moment, neglect the high costs, complexity, worldwide legality and PKI problems of crypto, which are all solvable at some cost. They aren't the fundamental problem.
Strong authetication answers the question:
That's a very nice to know if you need to place a high level of trust in the message, such as correspondance from your bank. Today email is virually worthless (in the absence of PGP) for trusted messages.
Saddly, the answer to this question is not valuable for filtering out junk. The question that needs to be answered instead is:
PGP does not answer this question. Neither does Yahoo's DomainKeys. There are many circumstances where the signature can not be verified. You can not use the failure to verify a PGP signature as a reliable means to filter out junk.
SPF and MS Caller ID are designed to answer this second question reliably enough to discard forged messages. They answer this question for all domains that publish SPF records (aol.com, gmail.com, etc) regardless of whether SPF is widely adopted by the rest of the world.
When the claimed domain published a list of designated senders, and the sending MTA's IP number isn't among them, you can be certain the message is a forgey and discard it (or close the connection before the data phase, saving bandwidth).
PGP and other crypto signature schemes simply do not deliver this ability to detect forgey. They only detect authenticity.
Yep, that's right
So, we all have to set up SPF records for our domains or our emails will get rejected by some ISPs. Is my understanding right?
Nope, that's wrong.
Messages only get rejected when a SPF does exist for the claimed domain and the MTA transmitting the message is not a valid sender for the claimed domain. Messages are NOT rejected simply because the claimed domain fails to publish a SPF record.
If you do not publish a SPF record, no messages claiming to be from your domain get rejected. This is true today, and it is likely to remain true even after SPF is widely deployed.
Of course, if you have a domain name, it is certainly in your best interest to publish a SPF record. Well, that is if your all email transmits from certain servers or one of the many other very flexible ways SPF's syntax can specify. Publishing a SPF record is the only way you can cause SPF-aware receivers to reject messages that claim to be from your domain, but are actually forged by spammers, virus programs, phishing scammers, and so on.
Sometimes this means an obscure URL parsing bug will allow phising scammers to make the browser display a URL of their choosing, thereby accurately impersonating credible banking websites and thousands of unsuspecting end users will fall victim to identify theft scams because their browser confirmed they were sending their sensitive info to their bank.
Sometimes it means memory will still be used after being freed, allows conditions that open the door for remote access with full administrative privs, resulting in hackers breaking into major sites and stealing massive lists of sensitive information, including thousands of customer credit card numbers.
Sometimes this means applications don't handle network data properly and buffers overrun in a database server that most people don't even realize they have installed, providing a mechanism for the fastest spreading internet worm of all time to greatly disrupt most internet traffic and effectively take down ATMs and lots of other important machines.
Sometimes it means poor design decisions emphasize ease of use at all costs, providing unskilled masses of users with a mechanism to accidentally execute malicious code attached to an email, with virtually nothing visually or otherwise distinguishing this dangerous (and detectable) circumstance from the ordinary way they conduct their jobs and exchance information with friends using email attachments that are not potentially dangerous.
Saddly, in the "real world", the choices Microsoft has made have clearly lead to much more harm than incomplete documentation, spelling errors, unavailable spellchecking and crashes in rare circumstances.
Whatever's in all those D-Link routers... you know, the ones that expose their configuation ability to the outside world with a master override password that can't be changed or turned off.
crashes more frequently
MacOS 6 through 9 (well, nothing can hold a candle to Win 3.1 for tendancy to crash, but certainly Apple has a much longer legacy of "one app takes the whole system down")
EULA more restrictive
Unix
slipped the scheduled release date more often and by a larger margin
GNU Hurd
To prevail in a copyright infringement suit, you need to prove two things:
- You own the copyright
- The copyrighted material was copied or distributed by the defendant
SCO's having trouble on both. Fail either one and they lose.Proving #2 is going to be nearly impossible for anyone in the future if IBM wins summary judgement or judgement at trial on their 10th counterclaim. Likewise, if Redhat wins.
Attempting to sue before these are decided may allow scumbags to spread a lot of hype, but any such case would probably be stayed until the IBM and Redhat cases are settled.
This outrageous intervention by industry had never been done on a matter of public health before.
Can you say "The Four Food Groups"? Knew ya could.
I'm sure there are plenty of great examples before 1950's, when the 4 food groups "public education" was written to cater to the politically important food producers, expecially the meat and dairy farmers. It's only been in the last 10 years or so that the myth of the 4 food groups has been replaced with the "food pyramid", despite decades of studies showing the emphasis on meet and diary to be unsound.
Here's an article about the numerous problems with the 4 food groups, and here's a quote from it:
Saddly, they do NOT need equivilant amounts of memory.
A modern Linux desktop needs MORE. A LOT MORE.
My girlfriend's machine has Win2K and usually runs Mozilla (mail and web), Quickbooks, UPS Wordship, Excel and Word 2000, iTunes and a half dozen little applets. IE is probably always taking up memory, as we've done nothing to disable or remove it. 512 megabytes of RAM seems to be fine.
My machine has Linux (roughly redhat9, kernel 2.4.20) and usually runs Mozilla, Openoffice, vmware (64 megs for an old win95 app), Nvidia's drivers, about 5-10 terminals, the gimp, a few vim sessions in them, gcc and other tools occasionally, some instances of xpdf, and usually a couple terminal emulators talking to hardware I'm developing. With only 512 megs, if I get a lot of stuff open, the system slows to a crawl. I recently bumped up to 1 gig of RAM and it runs well.
No.
First, it's under a protective order from the court. If they violate that, IBM will sue and destroy them... hopefully sooner with a temporary injunction rather than later with an ultimate verdict.
Second, much of the code was disclosed only to SCO's attorneys and not directly to SCO. See the complains from Computer Associates.
Third, SCO's unixware and openserver business is dying. Few (if any) new installations are being made. Even if they made dramatic improvements, those products are about as good as dead in the market due to a long history of neglect.
Fourth, their reputation is ruined. Nobody in their right mind will trust SCO now. And why should they, when "solutions" are readily available from large, stable companies with good reputations.... like IBM.
Fifth, they've already cut back (laid off employees), so their capability to illegally integrate lots of AIX code is reduced... and as things get worse for SCO this problem will only increase.
And finally, they will run out of cash soon anyway, with 4 lawsuits against corp heavyweights rapidly draining their funds. Their chances for further investment are slim, after the high profile Baystar dispute. Their stock has fallen enough that their ability to raise funds by issuing more shares is diminished, and if Kimball grants IBM even one bit of the summary judgement or makes a negative (for SCO) opinion in the Novell case, their stock valuation will be dropped back down to the sub $1/share where it rightly belongs.
Only a miracle is going to save SCO now... like Kimball buying their expansive theory of derivitive works, or suddenly finding a lot of directly copied SysV (not AIX) code inside of Linux.
I really like Sun, but this serves them right after paying SCO...
Are you suggesting that many years ago, when AT&T (USL) owned unix and no PC based OS was able to function as a server or do serious business work (eg, DOS 6 and Win 3.1 at the time), that Sun should have forseen that Unix code they licensed would eventually be sold to Novell, and then to old SCO, then various Calderas, and then Caldera would rename to SCO and finally replace its management with slimey bottom feeders who would attempt to be annoying to be bought out by IBM, and then failing that launch a rediculous shake-down scheme?
At least we'll have a whole week of major open source / free software figures publishing rebuttals.
One thing is pretty clear. Tanenbaum has dealt a blow to their credibility, enough to attack him rather than be quiet and avoid drawing more attention to their critics. That's a good sign that exposing ADTI/Brown for the deceptive corp whoring spin doctors they are is hurting them.
With any luck, next week's rebuttals will circulate widely and further drive ADTI's reputation down. The more ADTI suffers from this, the better it will deter other "research groups" from taking Microsoft's money to publish lies and deceptive spin.
Apart from the many advantages others have mentioned, in the long run the cost will be lower.
But what's the point of 1x slots? Plain PCI works just fine.
ISA and VLB worked just fine too.
A 1x PCIe slot is 250 Mbyte/sec (dedicated bandwitdh in both directions), whereas plain old 32 bit 33 MHz PCI is 133 Mbyte/sec (shared half-duplex amoung all slots on the same bus).
I'm assuming we will see boards with more than one 16x slot at some point
Probably not in the consumer realm.
Perhaps on servers... the segment of the market that today usually has 2 or 4 Opteron or Xeon CPUs and several PCI-X (64 bit, 133 MHz) slots.
Consider that a 4x PCIe slot is 1 Gbyte/sec (in both directions, dedicated bandwidth not shared with any other slots). That's fast enough for 10 Gbit/sec ethernet! Or a RAID0 array of TWENTY high speed drives (assuming a platter/spindle speed of 50 Mbyte/sec).
His most famous prediction, that most website would be funded by Micropayments in 2000 hardly came true.
The more pain this causes ADTI, the lower their future credibility sinks, the number of people whose long-term memories record ADTI as the bunch of corporate whores they are... the more damage is done to their prospects of seeking future funding. Even from Microsoft, it won't make sense to pour more money into ADTI if they are widely considered a joke.
Better yet, if ADTI suffers, the public scandal will help deter other "think tanks" from attacking free software when Microsoft or other proprietary vendors come knocking with "research" dollars.
Among the many questionable assumptions is that worms cost the world 50 billion dollars annually. Where did this soft number come from?
If you reject messages without a PGP signature, spammers will simply sign their messages.
If you reject based on the signing author being a known spammer, spammers will simply generate a new key for each message. This isn't a computational burden (as it is in PGP) if the keys aren't generated in a secure manner.
If you reject all unknown senders, people unknown in your "web of trust" will be rejected.
instruct unknown senders (people who aren't in my contact list yet) to download my public key from a specified location to encryp a message that would bypass my filtes.
These challenge-response systems are already in use today, by people willing to be rude to previously unknown senders. They suffer from all sorts of problems (out-of-office autoresponders, automatically generated shipping notices for online purchases, and other legitimate automated senders). How is adding the complexity of PGP an improvement?
The original statement is missing one important word "if [all] mail clients were configured".
This is an idea that just won't work if any significant number of senders still send out plain, old email as they currently do.
Contract with SPF and MS's Caller-ID, which are effective at detecting forgey when only the (claimed) sender publishes a SPF and/or Caller-ID DNS record and the receipient checks it.
To be successful, an change needs to provide value for those who have implemented it, even before widespread adoption occurs. SPF and MS Caller ID meet this goal, as people checking SPF and Caller ID can already reject forgeries claiming to be among 14000-some domain names (including AOL and Hotmail), and domain name admins who publish their SPF and/or Caller ID records are already receiving some protection from having their names forged.
The scheme "let's all switch to PGP" doesn't allow receivers to filter out messages until almost all legit senders sign their messages, and senders who sign their messages don't get much value from the signature until almost all receivers reject unsigned messages. Even then, PGP still suffers from the problem of unknown signatures, requiring a massive worldwide trust database or all the problems of callenge-response negotiation for new contacts.
PGP is an excellent answer to protecting privacy and proving strong authentication. Saddly, crypto only answers the question "is this message certainly authentic", but the question that needs answering is instead "is this message almost certainly a forgery".
Before the flag day, SPF will work the way it is now. After the flag day, which will probably occur later rather than sooner, SPF will have all the functionality of Caller ID. Here's a line to the post with the real info. Feel free to re-read it. Here's the sections about the "flag day". It's easy to see the "flag day" is about requiring forwarding MTAs to implement an extension to ESMTP, not the dual syntax of accepting either v=spf1 or xml (which will presumably occur very soon, since it doesn't impact anybody negatively, except people with a religious believe that one syntax ought to be universal.)
SPF doesn't block spam unless the mail system makes it mandatory, after all, so until 100% compliance is reached, non-SPF mail will still have to be accepted.
I'll type out an example, to show you exactly how it is already working and rejecting forgeries TODAY, without being mandatory, and long before widespread implementation.
Suppose your MTA receives a message from a spammer who is impersonating me. The message claims to be from "paul@pjrc.com", but it isn't. Your SPF-aware MTA (or spam filter) does a TXT query to my domain, and because my domain is one of the 14500-some returning SPF, you'll get this:
That means there's only two sources that are authorized to send messages for pjrc.com. So your software will first do a lookup on "outgoing.pjrc.com", sorta like this:If the IP number of the MTA sending the message is 168.143.160.91, then you know the message is coming from my server. If not, then the next authorized source is checked. Your software will do a MX lookup, like this:
Then, the name "main.pjrc.com" is looked up, such as:
If the MTA sending the message has the IP number 168.143.173.65, then you also know the message came from an authorized server for my domain, and thus the message is not a forgery by a spammer.
However, the last part of the SPF record was "-all", which means NO OTHER sources are authorized to send pjrc.com's email. So if the MTA sending the message is any IP number other than 168.143.160.91 or 168.143.173.65, then you know it's being sent from an authorized source, and thus it's a forgery (or I've messed up my SPF record).
Please take notice that for this to work, only you and I need to have SPF implemented. All the communication was between your receiving MTA (or SPF-aware spam filter), and my the DNS server for my domain. No other servers or other hosts on the internet needed to implement SPF in order for you to discover that a forged message isn't really from me.
Of course, only about 14500-some domains are currently publishing SPF records... so you can only detect forgeries if the spammer is foolish enough to forge one of our domain names. However, "aol.com", a very commonly forged name, is on the list. Likewise, "hotmal.com" is publishing caller ID (which works more or less the same as SPF, but with different syntax and with the minor distinction of sender vs from).
The bottom line is that your statement is incorrect. SPF does not have to be mandatory to function. It already works for those cases where the receiver bothers to check and the (claimed) sender publishes a SPF record. You can already reject all forgeries from 14500-some domains, including little ones like mine and big ones like AOL and Hotmail... and this is fully functional TODAY, long before 100% compliance is reached.
Really? How, exactly, are existing email headers anything like a DNS server that answers a query with a list of IP numbers that are the only ones authorized to transmit email for that domain?
In theory it says who's calling, but anyone dedicated can get around it.
Microsoft's Caller ID (and SPF) are about providing a DNS-based query that can be used to check if the IP number of the system sending the message is among the servers that are supposed to be sending that domain's email. Well, that's a bit over-simplified, but still the basic idea.
Caller ID and SPF aren't about adding an easily faked extra bit of info to the email headers. The IP number of the sending MTA is not easily faked, because SMTP uses TCP/IP which requires round-trip packet exchange, and the receiving MTA adds the "Received" line to the header with the verified IP number of the other MTA that sent the message.
To "get around it", a spammer who's forging someone else's domain name would have to be able to intercept or interfere with the receiver's DNS query. Very unlikely... especially when using open proxies, hacked home-user machines, free trial accounts, and anything else that's in no position to interfere with the receipient's DNS.
Of course, a spammer can also "get around it" by using a domain name that is under their control, and simply return a Caller ID or SPF result that says the IP number they are using is authorized (or that all IP numbers are authorized). This is what spammers will do (and reportedly some are already doing). But forcing spammers to use their own domain names is the goal of domain-name authentication.
Why don't they just call it like it is?
"Caller ID" in voice phone systems refers to the transmission of caller identify between the first and second ring. It seems you have assumed Microsoft's email Caller ID works roughly the same way, but it does not. The sender's IP number is always known (and virtually impossible to forge) because of the mechanics of TCP/IP, and Microsoft's Caller ID proposal is a query to the claimed source for a confirmation that the IP number is among the ones that are authorized to be sending.
A secure substitute for the "source" field of the e-mail header.
You completely misunderstood how it works. Hopefully you now understand.
The plan appears to be to support both XML and v=spf1 formats (according to the summary of the meeting between the SPF and Microsoft folkw). The expectation is that the vast majority of sites will publish the simple and compact v=spf1 format for the forseeable future. XML allows extensibility for the unforseen future that follows afterwards.
The important question is "is this message almost certainly forged". Signature checking can tell if that is _might_ be forged (the signature was missing or didn't match)... but unless you're among a very small minority of anti-spam activists, what you definately don't want is a "false positive" that accidentally filters out legitimate messages.
For crypto to be useful in filtering out junk, many things all have to work perfectly. You have to be absolutely certain that the claimed sender transmits ALL outgoing messages with valid signatures (high cost to implement, especially for large organizations with many servers). The signed portion of the message must not be modified by buggy servers or communications. You have to be able to get the public key. The sender has to manage their keys properly (keep expired ones around for delayed checks, keep the private key secret, properly update them as needed, and so on). If any of these things are less than highly reliable, the result is the signature does not match on an otherwise valid message.
The registrars are going to love that, since domain blacklists will quickly list any new domain they register and use to spam.
Even at volume domain name pricing, it's going to add considerable expense and difficulty for spammers to constantly buy new domain names names... or reuse ones already on blacklists.
Of course, whitelists will also probably develop in response to widespread adoption of domain name authentication.
I believe it could. If an attacker compromises any server with an outgoing MTA, they can probably get the private key. Maybe the on-disk copy will be encrypted, but I'd guess most admins won't want to have to type a passphrase every time the MTA needs to be restarted.
Signing messages like that sounds like a good idea
As I posted earlier, it sounds like a good idea, but I suspect it won't be really useful.... and not because of unrelated security weakness on servers.
DomainKeys can do a very good job of determining what a message is authentic. How useful is that? Here's two different questions you could ask about a message:
Being able to answer question #1 might be nice, but the answer to question #2 is that's useful for filtering out spam, virus messages, phishing scams, and so on.
To answer #2, first the legit sender domain needs to implement an outgoing signing policy of all messages signed. So ALL MTAs have to be updated to new code (as well as the policy and key(s) published by DNS). Without that policy and all MTAs correctly upgraded, all a spammer has to do is not include a signature at all (exactly what they do today), and the answer to both questions will be "No". Until you can answer "Yes" to question #2, you're doomed to see that spam and manually delete it (well, unless SPF or some conventional or bayesian filtering rules catch it).
In that case, I wonder what your opinion of DomainKeys will be, with its requirement (on top of a DNS record as in SPF) to modify your MTA to sign all outgoing message so that any users can use it.
Or maybe you were unaware of SRS... and perhaps also unaware that implementing DomainKeys requires not only the easy task of publishing a public key by DNS (which is all that SPF requires for most users), but also adding code to your MTA to sign the outgoing messages with your private key.
In section 3.7.1, domainkeys is supposed to either "verify" or "fail to verify" the message. To be useful in identifying spam, virus/worm messages, phishing scams and other junk, these two outcomes by correlate well with whether the message is desirable or junk. Or at the very least, at least one output must have a very low correlation with legitimate messages, because only the most agressive anti-spam advocates are willing to tollerate "false positives" (accidentally mistaking legit messages for spam)
Saddly, reading the rest of section 3.7 (and scanning most of the draft quickly), I'm seeing what looks like a lot of design that will cause "verify" to be a very strong indication that the message is good, but "fail to verify" seems like to correlate with spam/virus/scam, domainkeys not implemented, and a variety of configuration problems (not like computers would ever be configured incorrectly....)
I believe this binary output clause in section 3.7.1 doesn't match up well to the real world, where at least three board categories are likely:
Most people will only want messages rejected or filtered in condition #3, but accept then in #1 and #2. I strongly disagree with this conclusion from section 3.8:
Until DomainKeys it very widely deployed, condition #2 will be the norm.
Worse yet, it seems unlikely many large, well-known domain names (the ones spammers spoof the most) would select an outbound signing policy (section 3.6.2) indicating all outgoing messages are signed... at least until they've made sure ALL their MTA are upgraded and running DomainKeys flawlessly.
Saddly, it appears that the DomainKeys binary output of section 3.7.1 returns "verify" only on condition #1, and "fail to verify" in conditions #2 and #3. To be useful, especially in a gradual adoption phase, what is needed is a good indication of condition #3... when a message is most certainly junk and should be deleted.
If DomainKeys section 3.7.1 were rewritten for a 3 state output, and perhaps section 3.7.5 were replaced with something less vauge, and a more realistic way to act upon the results (section 3.8) is suggested... then DomainKeys would probably be as effective as SPF and MS's CallerID, but with the cost of only reworking transmission on forwarding MTAs to reworking transmission on all MTAs.
Or maybe I misunderstood something from the draft, or missed some part? Maybe someone will reply and explain why my pessimistic view of DomainKeys is misplaced?
BTW: full-disclosure, my domain is one of the 14500-some that is currently publishing a SPF record. I'll probably publish a MS CallerId record if the patent issues are cleared up, and if DomainKeys takes off, I'll probably add whatever patch signs outgoing messages too.