Too bad many, many ISP's block outbound port 25 to anything besides their own mail servers.
The SMTP server that you use SMTP AUTH or SMTP after POP does not have to be running on port 25. The SMTP SUBMISSION protocol runs on port 587. ISPs have little reason to block these other ports because you will only be able to connect to a very limited number of SMTP servers and they will usually want some sort of authentication.
Yes, but those cracked PCs will not be able to send email claiming to be from my domain to anyone who listens to my very restrictive SPF records. This will help reduce the number of bounces I back from forged sender addresses.
SPF is just one tool to help tighten up the security of the SMTP system. It lets domain owners say who is authorized to send email using their domain name. This is a useful thing to do, and it allows for other things to build on it. For example, RHSBLs that blacklist domain names instead of IP addresses are much more useful after SPF checking has been done. SPF checking can also help detect phishing schemes.
So, in essence, AOL has decided that it's customers can no longer send mail from their AOL email address, unless they're logged into AOL.
Their domain name, their rules.
If AOL was nice, they would provide SMTP AUTH, SMTP after POP, or the SMTP SUBMISSION protocol so that you could use their official mail servers from anywhere.
Yahoo's DomainKeys proposal involves taking a cryptographic hash of the message body *and* headers. It then encrypts the hash with a private key, puts the result in a header with a tag saying where to get the public key to check the resulting message.
The problems with Yahoo's Domainkeys, are as follows:
You complain about bounces, but this system does not verify the envelope from, and therefor will not prevent all those bounces.
A spammer who can get an account on your system (think Yahoo here), can send email to another account they control. They then have an email with your signed hash on it, which they can resend all they want.
Mailing lists, some email forwarding services, and other systems will add information to both the body and headers of a message. MicroSoft Exchange servers store emails in an internal format and recreate the heasers when they forward it on. *poof*, you now have an invalid hash.
Hashing and then using public key encryption to sign the emails is fairly expensive. The keys that you would look up in DNS are going to be fairly large. All-in-all, this is a fairly expensive proposal, and it doesn't really solve any problems.
I think SPF is a far better better proposal for this kind of thing.
Congratulations. You have just described how Yahoo's DomainKeys idea works, with the exception that DomainKeys also checks the headers.
The problem with your idea, and Yahoo's Domainkeys, are as follows:
You complain about bounces, but this system does not verify the envelope from, and therefor will not prevent all those bounces.
A spammer who can get an account on your system (think Yahoo here), can send email to another account they control. They then have an email with your signed hash on it, which they can resend all they want.
Mailing lists, some email forwarding services, and other systems will add information to both the body and headers of a message. MicroSoft Exchange servers store emails in an internal format and recreate the heasers when they forward it on. *poof*, you now have an invalid hash.
Hashing and then using public key encryption to sign the emails is fairly expensive. The keys that you would look up in DNS are going to be fairly large. All-in-all, this is a fairly expensive proposal, and it doesn't really solve any problems.
I think a far better better proposal for what you want to do is Sender Permitted From (SPF). It has been mentioned quite a few times on/. and elsewhere.
According to a message from Meng Weng Wong (the author of SPF), AOL will likely remove these SPF records today (Friday). There are still kinks that need to be worked out, and AOL doesn't like to make big changes like this to be permanent and/or last over the weekends until more testing has been done.
Well, yes, bind9 is supposed to support new DNS RR types. Unfotunately, from what I understand, all versions of bind9 have bug that creates a nasty catch-22. Only RR type numbers <255 work, but those numbers are reserved for standard track RFCs, but you aren't likely get a standard track RFC until you have shown that it works experimentally. The experimental RR type numbers don't work with bind9, so you are stuck.
Hadmut Danisch is the author of the RMX anti-spam proposal and his proposal is for a new DNS RR type of "RMX". I have little reason to doubt that he knows what he is talking about.
So I guess the checking tool is somewhat too strict (or the wizzard is sloppy.). explains the reported errors, though.
I just checked your domain name again, and the registry now reports your SPF record as being correct. As I mentioned above, this registry is new and bugs are obviously still being fixed. If you have other problems, please let me know. (I'm not involved in the registery, but I might be able to answer your questions.)
Re:How does this reduce spam in any shape or form?
on
SPF Design Frozen
·
· Score: 1
Okay, I am not trolling here, I'm serious.
You raise some good points, I'll try to address some of them.
SPF is not designed or intended to stop all forms of spam. In fact, I see SPF doing as much to protect people from phishing and joe-jobs as
reducing spam. UBE is not the only form of email abuse.
SPF gives domain name owners a voice to communicate which IP addresses, if any, are authorized to send email using the domain
name. Anyone who wants to listen to what the domain owner has to say is free to pay attention to this.
Widespread deployment of SPF may well help RHSBLs, but SPF itself has never intended to determine if a sender is good, bad, or ugly. It will also help with whitelists that use email addresses (as opposed to IP address whitelists.)
Not all email is equally important. I think SPF has good potential to be used by organizations such as financial institutions to reduce the chance of being phished and to damage the institution's good name.
While I can't see many major ISPs publishing restrictive SPF records, I can see them checking SPF records in order to help protect their customers. SpamAssassin will most likely have support for SPF in the 2.70 release and there are a couple of other anti-spam filters that will be checking it also.
SPF is a good step forward. It is not the only step that needs to be taken.
The reason why SPF sounds like RMX and DMP is because SPF is a hybrid of RMX and DMP. It is *much* further along with implementations and deployment, however. It is also, IMHO, much better thought out. The latest versions of RMX are actually much more like SPF was 6 months ago than like RMX was 9 months ago.
The registry was created only a few days ago and has doubled in size since I last checked. The SPF specifications were frozen only a week or so ago, and most of the parse errors are due to early adoptors not updating their records. The SPF libraries are now being updated to allow for some backwards compatibility, but I suspect that more of the records will just be fixed in the comming weeks.
I gave up in favor of SpamAssassin and Mozilla's spam filtering, which turned out to be far more effective.
I like SpamAssassin and use it myself. However, remember that one things that makes Spamassassin effective is their use of the SpamCop DNSBL. As a result, I report spam to spamcop in large part to make sure the spammers get listed on the SCBL. This seems to be a very effective technique to reduce the spam comming your way.
I've been thinking about this. I agree, Joker did not exercise
proper due diligence.
They *assume* that email is a reliable way of contacting someone, but
the *require* you to fax a document to them. I do not even have a fax
machine and, off hand, I don't know where I could send a fax from the
US to Germany. I suspect that it would cost at least a couple of
bucks and would take a fair amount of time.
They sent *one* email before shutting the domain down. They did not
reply to the (one) email that was sent in reply. I've never used
joker as a registrar, but I bet they send out more than just one email
to remind people to renew their domain.
The email that joker sent needs to be rewritten by someone who knows
english and to make it clearer. I found it quite ambiguous.
Granted, Julian freely admits that there was a bad phone number and
also that he didn't fax a response to them. Part of the fault does
lie with Julian, but I think far more lies with joker.
There is a new email worm called W32/Mimail-E that is designed to create a distributed denial of service attack on the anti-spam websites of spamcop, SPEWS, and spamhause. See: sophos write-up.
sitefinder is not dead as far as Verislime is concerned. They have only "temporarily" suspended it pending final resolution to the "technical problems" that it caused. Verislime is working hard to try and get them reinstated.
if [wilcarding TLD domainss is] legal then then BIND people would probably find themselves sued.
BUNK!
There is NOTHING that says that it is illegal for me to do post processing on DNS data that I receive from the internet. My server, my rules and if I want to block all of.biz,.cn and.edu with a patch to bind, nothing can (legally) stop me.
If you exceed the limit for a UDP answer, then the server performs another request using TCP. Considering this information would be cached with reasonable TTL's, I do not see the problem.
There are quite a few problems.
First, there is a very significant speed difference between a DNS query that gets handled via a single UDP packet (round trip), and one that requires the overhead of TCP's three-way handshaking.
Second, with Yahoo requiring thousands of RMX DNS resource records, everyone who wants to check to see if an IP address is ok is going to have to download quite a bit of stuff and then search through it all for the appropriate info. For people who are running spam filters at the slow end of a dial-up line, this is going to be real slow.
Third, with as many IP addresses that Yahoo will send email from, there are likely going to be updates to this list several times per week, if not several times per day. This means that the TTL's can't be that long.
Fourth, the it appears that the next draft of SPF will include provisions that let domain owners list individual IP addresses a-la RMX, if that really is the way they want to do things. SPF is a merger of ideas, and done in a way that the features compliment each other. Yes, SPF is more complicated than RMX, but not by that much. SPF is FAR more flexible and FAR more usable for both very simple domains (very common) and very large domains (very important).
The SPF system ties a domain to a set of IP addresses that allowed to send email claiming to be from that domain. In order to spoof the system, you have to be able to spoof the IP address that the SMTP TCP connection is coming from. While older operating systems had easily forged TCP sequence numbers, it is almost impossible to spoof a connection to a modern Unix system.
A slightly more possible way of spoofing the SPF system is to forged DNS packets so that the target MTA things that the spammer's IP address is ok. I don't think you need to worry about this attack much either. DNS spoofing isn't that easy to do in practice, there are fixes that could be imployed if this ever becomes widespread (add a nonce), and it will be far easier for spammers to just create throw-away domains that they can authorize all IP addresses to send email from.
SPF doesn't cure all the problems with email. It just makes it so that spammers and email worms can't forge your email address. The latter is at least as much of a problem as the former.
Re:Won't work unless everyone implements this
on
Spoofed From: Prevention
·
· Score: 4, Insightful
Nope, you didn't miss anything. Those people who don't care if spammers forge their domain name will likely have spammers use their domains. If the SPF system (or similar systems) become widespread, then receiving email from a domain that doesn't use SPF will become a strong indicator of spam and some people may choose to reject such email, or add in a score into spamassassin.
This is not much different than feel that they should be allowed to run open relays. They will end up on DNS blacklists and others may choose not to accept mail from them. Their server, their rules. No one is forcing anyone to close open relays, and no one is forcing anyone to accept email from everyone.
Read the website. Everyone will *not* have to do it. Only those domain owners that want to restrict who is allowed to send email using their domains will have to add SPF DNS entries. Only those people who want to obey the requests of domain owners will have to check the SPF DNS entries.
I have looked at quite a few of the various "designated sender" systems, and I think that the SPF system is by far the best thought out system. There is a reasonable good comparison of SPF vs RMX vs DMP available on the SPF website.
Basically, RMX has to critical flaws. First, it requires a new DNS resource record type, which is going to require everyone to upgrade their name servers if they want to use it. Secondly, there is a limit to how many resource records can be sent in a UDP packet and many important ISPs such as AOL, MSN, Yahoo, etc., have far to many. If I recall correctly, there are several thousand(!) IP addresses that Yahoo will send email from.
The SPF system is far less complicated than GPG in almost every way.
That being said, the SPF system is not intended to be the only tool that will help create a more trustworthy mail system. I haven't heard anyone involved in the SPF system argue against using all appropriate tools.
There is also the point that SPF is designed to help determine if someone is authorized to use a domain name, while GPG is designed to authenticate who is sending the email. These are different problems, so SPF and GPG complement each other.
This is incorrect. RTFA. The SPF, and other designated sender systems, are all about preventing joe-jobs and forging of the mail-from addresses. (and no, not all forged mail-froms are joe-jobs, theyare not the same thing.)
I installed linux on a redundant P3 lying around and set things up because I didnt want to hit the management with a bill for some fancy UNIX solution, andI'm just used to linux.
I think the freedom to "just do it" is as significant a factor as the free price and the freedom to modify the code. The ability to download open source software, install it on an old, redundant computer, and play around with it without having to ask anyone for permission or money is a huge factor. Even if the techie knows that his boss will probably approve the money, it is still a hassle. The boss might say "no", the boss might not be around, the boss might use the discussion to bring up other, unpleasant things, such as WTF those clueless users in Marketing are demanding right now.
Of course, this "freedom from hassles" is also why people use the software that is installed by default on the computers they buy instead of going through the hassles of downloading OSS. It does cut both ways. This changes when it is time to upgrade the system, and then the hassle factor comes back in. If you can upgrade that Win98 box to Linux without having to get permission, then even if the TCO is higher for OSS, it will still get done.
Slashdot Mirror
The SMTP server that you use SMTP AUTH or SMTP after POP does not have to be running on port 25. The SMTP SUBMISSION protocol runs on port 587. ISPs have little reason to block these other ports because you will only be able to connect to a very limited number of SMTP servers and they will usually want some sort of authentication.
SPF is just one tool to help tighten up the security of the SMTP system. It lets domain owners say who is authorized to send email using their domain name. This is a useful thing to do, and it allows for other things to build on it. For example, RHSBLs that blacklist domain names instead of IP addresses are much more useful after SPF checking has been done. SPF checking can also help detect phishing schemes.
Their domain name, their rules.
If AOL was nice, they would provide SMTP AUTH, SMTP after POP, or the SMTP SUBMISSION protocol so that you could use their official mail servers from anywhere.
The problems with Yahoo's Domainkeys, are as follows:
I think SPF is a far better better proposal for this kind of thing.
The problem with your idea, and Yahoo's Domainkeys, are as follows:
I think a far better better proposal for what you want to do is Sender Permitted From (SPF). It has been mentioned quite a few times on /. and elsewhere.
See: this message on the SPF mailing list
I have to admit that I haven't actually tried creating new ones, so I'll defer to someone who has. See: IETF ASRG RMX mailing list: Hadmut Danisch on creating new DNS RR types
Hadmut Danisch is the author of the RMX anti-spam proposal and his proposal is for a new DNS RR type of "RMX". I have little reason to doubt that he knows what he is talking about.
So I guess the checking tool is somewhat too strict (or the wizzard is sloppy.). explains the reported errors, though. I just checked your domain name again, and the registry now reports your SPF record as being correct. As I mentioned above, this registry is new and bugs are obviously still being fixed. If you have other problems, please let me know. (I'm not involved in the registery, but I might be able to answer your questions.)
You raise some good points, I'll try to address some of them.
SPF is not designed or intended to stop all forms of spam. In fact, I see SPF doing as much to protect people from phishing and joe-jobs as reducing spam. UBE is not the only form of email abuse.
SPF gives domain name owners a voice to communicate which IP addresses, if any, are authorized to send email using the domain name. Anyone who wants to listen to what the domain owner has to say is free to pay attention to this.
Widespread deployment of SPF may well help RHSBLs, but SPF itself has never intended to determine if a sender is good, bad, or ugly. It will also help with whitelists that use email addresses (as opposed to IP address whitelists.)
Not all email is equally important. I think SPF has good potential to be used by organizations such as financial institutions to reduce the chance of being phished and to damage the institution's good name.
While I can't see many major ISPs publishing restrictive SPF records, I can see them checking SPF records in order to help protect their customers. SpamAssassin will most likely have support for SPF in the 2.70 release and there are a couple of other anti-spam filters that will be checking it also.
SPF is a good step forward. It is not the only step that needs to be taken.
The reason why SPF sounds like RMX and DMP is because SPF is a hybrid of RMX and DMP. It is *much* further along with implementations and deployment, however. It is also, IMHO, much better thought out. The latest versions of RMX are actually much more like SPF was 6 months ago than like RMX was 9 months ago.
The registry was created only a few days ago and has doubled in size since I last checked. The SPF specifications were frozen only a week or so ago, and most of the parse errors are due to early adoptors not updating their records. The SPF libraries are now being updated to allow for some backwards compatibility, but I suspect that more of the records will just be fixed in the comming weeks.
I gave up in favor of SpamAssassin and Mozilla's spam filtering, which turned out to be far more effective.
I like SpamAssassin and use it myself. However, remember that one things that makes Spamassassin effective is their use of the SpamCop DNSBL. As a result, I report spam to spamcop in large part to make sure the spammers get listed on the SCBL. This seems to be a very effective technique to reduce the spam comming your way.
They *assume* that email is a reliable way of contacting someone, but the *require* you to fax a document to them. I do not even have a fax machine and, off hand, I don't know where I could send a fax from the US to Germany. I suspect that it would cost at least a couple of bucks and would take a fair amount of time.
They sent *one* email before shutting the domain down. They did not reply to the (one) email that was sent in reply. I've never used joker as a registrar, but I bet they send out more than just one email to remind people to renew their domain.
The email that joker sent needs to be rewritten by someone who knows english and to make it clearer. I found it quite ambiguous.
Granted, Julian freely admits that there was a bad phone number and also that he didn't fax a response to them. Part of the fault does lie with Julian, but I think far more lies with joker.
There is a new email worm called W32/Mimail-E that is designed to create a distributed denial of service attack on the anti-spam websites of spamcop, SPEWS, and spamhause. See: sophos write-up.
sitefinder is not dead as far as Verislime is concerned. They have only "temporarily" suspended it pending final resolution to the "technical problems" that it caused. Verislime is working hard to try and get them reinstated.
BUNK!
There is NOTHING that says that it is illegal for me to do post processing on DNS data that I receive from the internet. My server, my rules and if I want to block all of .biz, .cn and .edu with a patch to bind, nothing can (legally) stop me.
There are quite a few problems.
First, there is a very significant speed difference between a DNS query that gets handled via a single UDP packet (round trip), and one that requires the overhead of TCP's three-way handshaking.
Second, with Yahoo requiring thousands of RMX DNS resource records, everyone who wants to check to see if an IP address is ok is going to have to download quite a bit of stuff and then search through it all for the appropriate info. For people who are running spam filters at the slow end of a dial-up line, this is going to be real slow.
Third, with as many IP addresses that Yahoo will send email from, there are likely going to be updates to this list several times per week, if not several times per day. This means that the TTL's can't be that long.
Fourth, the it appears that the next draft of SPF will include provisions that let domain owners list individual IP addresses a-la RMX, if that really is the way they want to do things. SPF is a merger of ideas, and done in a way that the features compliment each other. Yes, SPF is more complicated than RMX, but not by that much. SPF is FAR more flexible and FAR more usable for both very simple domains (very common) and very large domains (very important).
A slightly more possible way of spoofing the SPF system is to forged DNS packets so that the target MTA things that the spammer's IP address is ok. I don't think you need to worry about this attack much either. DNS spoofing isn't that easy to do in practice, there are fixes that could be imployed if this ever becomes widespread (add a nonce), and it will be far easier for spammers to just create throw-away domains that they can authorize all IP addresses to send email from.
SPF doesn't cure all the problems with email. It just makes it so that spammers and email worms can't forge your email address. The latter is at least as much of a problem as the former.
This is not much different than feel that they should be allowed to run open relays. They will end up on DNS blacklists and others may choose not to accept mail from them. Their server, their rules. No one is forcing anyone to close open relays, and no one is forcing anyone to accept email from everyone.
Read the website. Everyone will *not* have to do it. Only those domain owners that want to restrict who is allowed to send email using their domains will have to add SPF DNS entries. Only those people who want to obey the requests of domain owners will have to check the SPF DNS entries.
Basically, RMX has to critical flaws. First, it requires a new DNS resource record type, which is going to require everyone to upgrade their name servers if they want to use it. Secondly, there is a limit to how many resource records can be sent in a UDP packet and many important ISPs such as AOL, MSN, Yahoo, etc., have far to many. If I recall correctly, there are several thousand(!) IP addresses that Yahoo will send email from.
That being said, the SPF system is not intended to be the only tool that will help create a more trustworthy mail system. I haven't heard anyone involved in the SPF system argue against using all appropriate tools.
There is also the point that SPF is designed to help determine if someone is authorized to use a domain name, while GPG is designed to authenticate who is sending the email. These are different problems, so SPF and GPG complement each other.
This is incorrect. RTFA. The SPF, and other designated sender systems, are all about preventing joe-jobs and forging of the mail-from addresses. (and no, not all forged mail-froms are joe-jobs, theyare not the same thing.)
VeriSlime t-shirt "No Values to Trust"
VeriSlime t-shirt "The Abuse of Trust"
I think the freedom to "just do it" is as significant a factor as the free price and the freedom to modify the code. The ability to download open source software, install it on an old, redundant computer, and play around with it without having to ask anyone for permission or money is a huge factor. Even if the techie knows that his boss will probably approve the money, it is still a hassle. The boss might say "no", the boss might not be around, the boss might use the discussion to bring up other, unpleasant things, such as WTF those clueless users in Marketing are demanding right now.
Of course, this "freedom from hassles" is also why people use the software that is installed by default on the computers they buy instead of going through the hassles of downloading OSS. It does cut both ways. This changes when it is time to upgrade the system, and then the hassle factor comes back in. If you can upgrade that Win98 box to Linux without having to get permission, then even if the TCO is higher for OSS, it will still get done.