Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||
Debian rejects Sender ID
------------------------------------------------------------------------ The Debian Project http://www.debian.org/News/ Debian project unable to deploy Sender ID press@debian.org September 4th, 2004 http://www.debian.org/News/2004/20040904 ------------------------------------------------------------------------ DEPLOY: Debian project unable to deploy Sender ID This message summarises the position of the Debian project, producer of the universal operating system: Debian GNU/Linux. The Debian project abides by a social contract to our users that specifies all software included in the operating system will be Free Software, meaning that it can be freely redistributed, modified, used, etc. as defined under the Debian Free Software Guidelines (DFSG) The current Microsoft Royalty-Free Sender ID Patent License Agreement terms are a barrier to any Debian package which wants to implement Sender ID or include Sender ID support. We believe the current license and resulting encumbrances are incompatible with the DFSG, unlike other Internet standards that Debian is able to support. Therefore, we cannot implement or deploy Sender ID under the current license terms. Indeed, we would be forced to remove SenderID support from software we ship that does support Sender ID upstream according to the terms of our social contract. For the most part, our legal concerns mirror those of the Apache Software Foundation, the Free Software Foundation, as well as the Postfix, Exim, and Courier maintainers. We are also concerned that no company should be permitted intellectual property rights (IPR) over core Internet infrastructure. We believe the IETF needs to revamp its IPR policies to ensure that the core Internet infrastructure remain unencumbered. With thanks to the Apache Software Foundation for their statement, which we used as a starting point, though we have arrived at our determination independently. Additional information: Debian Social Contract http://www.debian.org/social_contract Debian Free Software Guidelines http://www.debian.org/social_contract#guidelines Apache Statement on Sender ID http://www.apache.org/foundation/docs/sender-id-position.... -- To UNSUBSCRIBE, email to debian-news-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org (Log in to post comments)
That much trouble? Posted Sep 5, 2004 19:16 UTC (Sun) by philips (guest, #937) [Link] I cannot get it: piece of software proved to be ineffective causes that much trouble?
Why just not try to develop another protocol and finally retire POP3/SMTP/IMAP?
Why cannot open source developers try to come up with some simple protocol? - and implement
P.S. ssh did not need years to come up with ways to detect identity forgery - why it takes that
That much trouble? Posted Sep 5, 2004 19:29 UTC (Sun) by philips (guest, #937) [Link] [Follow up]
Sorry - we need to retire only SMTP. POP3/IMAP are already support authentication.
If we will draw a parallel with IP addresses - e-mail addresses are not much different.
When we build a new house - it takes time for post office to assign new address. Probably e-
e-mail assignment must be slow and complicated process. So if someone tries to make up a
P.S. Maintenance of registry will cost some money - that's true. But if every one will pay one cent
Umm... I hate to take away your last example Posted Sep 6, 2004 1:26 UTC (Mon) by Ross (subscriber, #4065) [Link] But please google for SMTP authentication. SMTP auth exists and is supportedin all the major MTAs. Getting people to use it is another issue.
Umm... I hate to take away your taking away of the last example Posted Sep 6, 2004 16:55 UTC (Mon) by gwolf (subscriber, #14632) [Link] It does not solve the problem. SMTP authentication makes it necessary for you to authenticate with a server in order for it to accept your mail and relay it. It does not, however, require anything from you in order to deliver you a message created somewhere else for a local user.The problem with spam is that it is too easy to set up a simple SMTP server. It is so easy that hundreds of people do it even without knowing. It is also an important problem with viruses/worms: You might not even know you have a SMTP client in your machine happily sending mail everywhere it can!
Umm... I hate to take away your taking away of the last example Posted Sep 7, 2004 1:10 UTC (Tue) by Ross (subscriber, #4065) [Link] I basically agree with your first paragraph. SMTP authentication doesn'tprevent receipt of spam, but it does prevent anonymous sending of spam.
You lose me in your second paragraph. Spammer's don't need to run SMTP
That much trouble? Posted Sep 5, 2004 20:29 UTC (Sun) by nigelm (subscriber, #622) [Link] > Why just not try to develop another protocol and finally retire POP3/SMTP/IMAP?
Well its only SMTP thats an issue here. And the problem is that its a hard problem, and you have an installed based of many millions or maybe billions of installations - and you want to just sweep this away?
You can only do end to end identity management of email if you have a close user group of some sort. Now of course MS could provide that (and AOL used to) - and leave the rest of the world on the outside.
As for the comparisons against ssh, well yes, if you only want the small number of people who can ssh into your boxes be able to email you, then thats fine. I personally need to email people I have never had previous contact with. And I get legit emails from a lot of other people that I have had no previous relationship with, and not even any link to the ISP or company.
If I really wanted full end to end management I might use X400 - but there are reasons thats damn close to dead.
That much trouble? Posted Sep 5, 2004 21:32 UTC (Sun) by khim (subscriber, #9252) [Link] ssh did not need years to come up with ways to detect identity forgery - why it takes that much time to implement it for e-mail? Hmm... Good question... Especially since we had a solution for this problem for almost 10 years: RFC1847, RFC2015, etc. Way before spam become real problem. Yet... there are still this nasty spam problem and nothing is solved. Why so ? Easy. Problem is with users, not with SMTP. What mail users demand is the following: That's all. Since there are no sane way to implement both 1. and 2. simultaneously we end up with all this mess like SenderID and such. That's all. As usual there are no technical solution for social problems: people should either accept spam and live with it or they should accept lack of anonymity. You can not have both.
That much trouble? Posted Sep 5, 2004 22:17 UTC (Sun) by doogie (subscriber, #2445) [Link] pgp-mime has nothing to with allowing one to send mail. It's only for making sure it isn't modified in transit, can't be read by unknown third parties, and that the sender is who they say they are. It has no bearing on mail routers in the middle, nor the mail routers on each end point.
That much trouble? Posted Sep 5, 2004 22:36 UTC (Sun) by khim (subscriber, #9252) [Link] And what SPF/SenderID is ? Easy: it's try to reject mail from someone who's pretending he/she is now what he/she is. pgp-mail does is way better then any patented scheme. Yes, it needs some changes in end-user agents, but SPF/SenderID needs these changes as well! Of you can add proxy in the process. The same as with pgp. If you say: "SenderID is different solution" I'll agree. If you say: "SenderID is better solution" then I want clarifications. It's pretty easy to add "reject non-pgp signed mail" rule to senmail or other MTA - it's just deemed "too intrusive". Thus instead of good and tested solution we're stuck with bunch of half-backed "extensions" and stupid "authentification schemes".
That much trouble? Posted Sep 6, 2004 16:03 UTC (Mon) by TwoTimeGrime (guest, #11688) [Link] > Easy: it's try to reject mail from someone who's pretending he/she> is now what he/she is. pgp-mail does is way better then any > patented scheme.
pgp-mail requires you to receive the entire email before making a decision. SPF does not. That saves bandwidth.
SPF isn't covered by a patent. You can use it. It's working now to stop joe-jobs. See this link for a good overview: http://yro.slashdot.org/comments.pl?sid=119211&cid=10...
> Yes, it needs some changes in end-user agents, but SPF/SenderID
SPF does not require a change in end-user agents. It can and does work at the MTA level.
"It's not a bug ... it's a feature" Posted Sep 6, 2004 18:42 UTC (Mon) by freemars (subscriber, #4235) [Link] pgp-mail requires you to receive the entire email before making a decision. SPF does not. That saves bandwidth. The bandwidth costs the spammer (or the major ISP which doesn't block mail from zombied computers) as much as it costs you. You can do your part to drive the cost of spam up. Think of it as a tarpit. Further downthread people are saying how PGP'd spam would do more to hurt encryption than spam; they're probably right (imho).
That much trouble? Posted Sep 5, 2004 23:02 UTC (Sun) by Russell (guest, #1453) [Link] It may be possible to satisfy both 1 and 2.
1. Satisfied by only accepting mail from a list of authorised. Use signatures to do this. We then need only protect the keys from viruses. That is a problem programmers can solve ( not a social issue ).
2. Allow people to send spam. ( Nobody will be listening anymore )
That much trouble? Posted Sep 6, 2004 1:36 UTC (Mon) by khim (subscriber, #9252) [Link] Right, but... Try to think about it again. When I talk about 2) I do not talk about professional spammers! I talk about normal lawful internet citiziens. They do want to send anonymous mail to this or that website and/or to this or that mailing list. All the time. It's not some obscure twist - a lot of peoples become very nervous if you'll suggest some theme when mail can be easily tracked to physical person. This is good and all, but... if you can not trace back "normal" sender (who never even seriusly attempted to to cover tracks!) how the hell can you ever hope to trace back professional spammer ? This is what I meant above: people somehow think magic SenderID or something can make spammers easily trackeable but still will not affect anonymity of "lawful citiziens". It's impossible. And if you'll trink about it pgp-mail does exactly what you're proposing. It was around for more the 10 years. It's still not widely used. Why ? Since pgp-mail (once you'll demand correct signatures with keys registered on few well-controlled key-servers) will "greatly affect privacy - and we do not want it". But if you got privacy then why can not spammers get privacy the same way (no matter what authentification scheme is in use) ? Think about it...
The expectation of anonymity issue Posted Sep 6, 2004 5:33 UTC (Mon) by eru (subscriber, #2753) [Link] Why so ? Easy. Problem is with users, not with SMTP. What mail users demand is the following:1. I do no want to get spam (== mail from unknown anonymous recepients). 2. I must be able to send spam (== anonymous mail via unregistered ISP). I'm certain most users would be very happy to compromise on 2 if it would ensure 1. Until some years ago, most ordinary users actually assumed that "from" e-mail addresses are reliable and messages are traceable. It did not deter them from using e-mail. Only the spam catastrophe has made people more widely aware that the "from" field is just an arbitrary text that may have no relation to reality. Set up an alternate e-mail system that has no anonymity, but no spam or viruses either, and I think a lot of users would be interested.
That much trouble? Posted Sep 6, 2004 10:23 UTC (Mon) by ikm (subscriber, #493) [Link] The truth is, people WANT to live with spam. Because they tend to accept the offers from the spam letters. No one would ever send a spam otherwise, because it just would not help advertising.
So, it is actually a possible scenario, where people can both 1) have a possibility to send the spam and 2) never receive any spam at the same time... but not on that planet, or at least not today or tomorrow. The possible social solution against the spam in that manner would be for the mail filters to get each detected spam message through, but with the banner attached to each message explaining why all the spam should be ignored regardless of the offering in it. But it is really hard to change people that way.
That much trouble? Posted Sep 5, 2004 22:25 UTC (Sun) by neilbrown (subscriber, #359) [Link] Why cannot open source developers try to come up with some simple protocol? - and implement it for exim/postfix/sendmail. After all, this packages route crucial amount of post on internet - and all of them are open source.They did. It's called "SPF". Lots of people have said how flawed it is, but as long as you have your expectation set right, it does a completely adequate job. By "expectation", I mean it doesn't defeat spam, and it doesn't defeat phishing, but then it cannot as those are both very much human-factors problems. It can defeat forging, and this is an essential input to any automatic tool which could help attack spam and phishing. As far as I could see, SPF was pretty much on track right up until IETF got involved....
That much trouble? Posted Sep 6, 2004 1:38 UTC (Mon) by jamesh (subscriber, #1159) [Link] I cannot get it: piece of software proved to be ineffective causes that much trouble? What makes you say that SPF and/or SenderID are ineffective? If you are referring to things like the recent Register article, then you are missing the point. SPF is about authenticating that a piece of mail came from where it says it came from. The fact that you can authenticate that a message comes from the sender does not mean that it is not spam. However it might prove that the spam came from a domain owned by a known spammer, which might be useful to your spam filter. Authentication will also mean that if you get a message from your bank, it will have come from your bank rather than a phisher. And it should virtually stop the spread of mass mailing email viruses that forge the sender address (something that should please people not using Windows ...). Of course to be effective, any of these protocols need wide adoption. The Microsoft patent could very well make Sender ID ineffective, which is what this article is about. However, it looks like SPF does not have this problem.
That much trouble? Posted Sep 6, 2004 2:59 UTC (Mon) by paulj (subscriber, #341) [Link] SPF in providing a check that a mail comes from an MTA which is authorised to send for that domain, breaks many common email setups, forwarded SMTP accounts being the big one. Do i have to go configure my MUA to connect to different SMTP servers for each address I have hosted at different places? What if my ISP blocks SMTP? Ah, use MSA.. what about when ISPs start blocking that?), while doing absolutely *nothing* to solve spam. Indeed, Spammers have enthusiastically adopted SPF and at present the majority of email with valid SPF is spam! SPF: breaks many valid and common SMTP uses and has 0 effect on spam. Yay for SPF!
That much trouble? Posted Sep 6, 2004 6:33 UTC (Mon) by neilbrown (subscriber, #359) [Link] This is a common misunderstanding of SPF.
SPF doesn't break anything and is not expected to prevent spam.
SPF simply provides a score - PASS, FAIL, UNKNOWN, ERROR (or something like that). What you do with that score is up to you.
This score is *not* a measure of how likely it is spam (though there is a correlation today, it is dropping). But that is not how you use the score.
I currently use the score like this: If it isn't PASS, and the mail contains a potentially executable attachment, drop the mail. This kills all mass-mailer viruses at very little cost.
If I ever implement a challenge-response system, it would use the score to say "Only send a challenge if the score is PASS", otherwise you might be spamming innocent people with your challenges. If the score is not PASS, and the address isn't on my white list, then I probably don't read the mail, though a very, very low spam assassin score might let it get through to me.
SPF doesn't address spam *at*all*. It addresses forgery. Once you have eliminated forgery, then other anti-spam measures like challenge-response and white-lists become must more useful.
The "breaks forwarding" is a very common misconception. Rejecting all SPF-fail messages would break forwarding, but such behaviour is not rational. Presumably you know everone who you expect to forward mail you. These sites can be whitelisted (if you trust them) or discontinued (if you don't).
That much trouble? Posted Sep 6, 2004 7:50 UTC (Mon) by khim (subscriber, #9252) [Link] It addresses forgery. Yeah, right. There are 3 millions .com domains. God knows how many in .XX for different countries and so on. More then thousand of new domains are created each day in .com. And I'm not even talking about domains of 3-4-5 level. And the only way to track someone with SPF is to ask domain owner (often - not real person as well). The sad truth is that you can not trace sender with SPF: it's too weak to be used as court argument, for example. Any scheme where you can easily track physical sender will be rejected by masses (we already had one for more then 10 years - PGPmail or S/MIME) and if you can not do it then it'll be useless against spammers. Just like SPF is useless and will become even more useless if the future.
That much trouble? Posted Sep 6, 2004 10:35 UTC (Mon) by neilbrown (subscriber, #359) [Link] I think your understanding of "forgery" must be different to mine.
I mean "sending mail claiming to be from the address of some person, but not really being sent by that person".
It doesn't matter how many new domains there are every day.
It also doesn't matter whether I can track down who actually sent the forgery or not.
It just matters whether I can tell if a mail item is a forgery or not. That is the point of SPF and it does a very adequate job.
That much trouble? Posted Sep 6, 2004 13:44 UTC (Mon) by khim (subscriber, #9252) [Link] I think your understanding of "forgery" must be different to mine. Hmm. Are you sure ? If mail is sent from domain where are no real users at all are registered (just SPF records and some cracked SMTP server) it's forgery or not ? I mean "sending mail claiming to be from the address of some person, but not really being sent by that person". Hmm... What about "mail sent from god knows where and by god knows whom" ? That's the real problem with spam, right ? It just matters whether I can tell if a mail item is a forgery or not. That is the point of SPF and it does a very adequate job. No, it does not. If I'm concerned about my regular correspondents PGP does much more adequate job. And when I'm concerned about others it does not make much difference to me if it's mail from joe@somewhere.com or joe@someplace.com if both joe@someplace.com and joe@someplace.com can not be traced back to physical person. Domain names are meaningless - you need to stop real physical person or you'll fight windmills forever.
That much trouble? Posted Sep 6, 2004 15:20 UTC (Mon) by jamesh (subscriber, #1159) [Link] Hmm. Are you sure ? If mail is sent from domain where are no real users at all are registered (just SPF records and some cracked SMTP server) it's forgery or not ? I wouldn't call that a forgery. The SPF records tell you that the message was sent from a server authorised by the domain name holder. It doesn't tell you whether you can trust the domain name holder though (and has never claimed to).
That much trouble? Posted Sep 6, 2004 15:26 UTC (Mon) by khim (subscriber, #9252) [Link] I do not ask you "is it forgery from SPF point of view". I ask you "is it forgery or not". I know what SPF does. It's just what SPF does is useless: it adds new hoops for "honest" people and adds very small protection against type of forgery used by spammers.
That much trouble? Posted Sep 6, 2004 18:10 UTC (Mon) by marble (subscriber, #2719) [Link] You wouldn't say that when you're treated to thousands of bounces, hatemailsetc, cos some spammer has decided to send email from your address. This happens, SPF offers a solution. SpamAssassin already does a fairly decent job of filing spam away in the bit bucket so with widespread adoption of SPF, I'd be happy. (Yes, it has happened to me.)
That much trouble? Posted Sep 6, 2004 19:42 UTC (Mon) by paulj (subscriber, #341) [Link] But you can protect against bounces with outbound-envelope-cookie schemes like SRS. Further, with SRS, you protect *yourself*, you dont rely on other people to check SPF first before sending a bounce to you.
Unlike SPF, outbound-cookies dont break, the very common, use of SMTP forwards.
SPF! It "authenticates" (cough) mail from my domain, Yay for SPF!
/me uninstalls gnupg
That much trouble? Posted Sep 6, 2004 20:30 UTC (Mon) by rdowner (subscriber, #3960) [Link] A few months ago I was "joe-jobbed". A spammer, for several weeks, was sending out spams forged to appear from my domain. The invalid email addresses were, of course, bounced back to *me* -- several hundred *a day*. If those mails servers processing the received mail support SPF (and if I had an SPF record on my domain), I would not have bombarbed with the "shrapnel" -- the receiving mail servers would have realised that it wasn't me sending the e-mail and would not have even accepted them for delivery. This would have saved me the problem of suddenly getting hundreds of messages in a short period of time, desperately reconfiguring my mail setup trying to stem the flow of bounces, and inevitably losing some of my valid mail in the process
No, SPF will not solve the spam problem, cure all disease or bring about world peace. But it will solve *some* problems, such as the problem I've just described. There is money to be made in spam and there is no doubt that the professional spammers will find new ways to get the spam delivered. However, today, I believe there is value in SPF - it will stop a class of spam attack (assuming SPF is widely adopted). It doesn't add "hoops" for the vast majority of people, as ISPs will simply need to update their DNS records with info on their mail servers and their end users need take no action (it has been remarked that "mobile" users may have some issues but there are workable solutions to that too.)
regards,
That much trouble? Posted Sep 6, 2004 9:08 UTC (Mon) by jamesh (subscriber, #1159) [Link] The mail forwarding issue is known to the SPF developers, and they have a solution (SRS and whitelists). Getting the solution implemented is part of the problem of getting the system adopted. As for the article you linked to, it is about the same survey as the one I linked to. The results are not that surprising either. If you expect an SPF pass to mean that a message is not spam, then you will be disappointed. One thing that the survey didn't touch on is whether any of the spams received claimed to come from their customers and passed the SPF checks. I'd guess that the answer would be no. As a comparison, would you deploy a spam filter that let through all messages that had a valid PGP signature? I bet that if such a filter was developed, spammers would start generating PGP keys and signing all their spam. If this happened, would you consider PGP to be useless? I wouldn't, since none of the spams would be signed with my key.
That much trouble? Posted Sep 6, 2004 10:08 UTC (Mon) by ametlwn (subscriber, #10544) [Link] I bet that if such a filter was developed, spammers would start generating PGP keys and signing all their spam. If this happened, would you consider PGP to be useless?I would consider pgp to be useless as anti-spam measure. The same way many people consider SPF to be useless as anti-spam measure (except for very short term). I wouldn't, since none of the spams would be signed with my key.None of the mail I receive is signed with my key either, I rarely correspond with myself. ;-) But more seriously, GPG/PGP's functionality indeed would not suffer at all if spammers used it, I'd still be able verify the authenticity of mail signed with a key which I have trustpath to.
That much trouble? Posted Sep 6, 2004 10:41 UTC (Mon) by khim (subscriber, #9252) [Link] The fact is: with PGP you know who to trust and wuth SPF you do not. You trust some random DNS server - and there are literally thousands of points where you can add your server without much checking. SPF is designed with the stupid idea in mind: you should trust any server with valid SPF information. That's absurd. PGP, on the other hand is designed to live in hostile environment: it's not enough to have valid PGP signature in mail. You somehow should be in trustpath. Plus you need to sign each and every outgoing mail - just add requirement to sign From: and To: lines as well and voila - great strain for initial sender (==spammer). Relay do not change signature at all so they are not affected.
That much trouble? Posted Sep 6, 2004 13:29 UTC (Mon) by arafel (subscriber, #18557) [Link] If receiving servers are expected to verify that a PGP signature is valid, that's quite a lot of work added to the machine. If they're not expected to verify it as valid, then what do you gain? You've still received the spam.
Basically, I don't think I understand your point. A mail being PGP signed proves absolutely nothing except that the sender had a copy of PGP. (Or GPG, if you're being picky :)
That much trouble? Posted Sep 6, 2004 13:52 UTC (Mon) by khim (subscriber, #9252) [Link] Argh. Of course receiving servers do not need to verify PGP signature - they do not even need to check if it's there or not. End-user mail agent will do it. And as for "simple PGP signed (by unknown key) mail" being not better then normal mail - it's not. It's harder to create and you can not generate 1'000'000 different PGP keys with ease. Plus if you can not find key on public keyserver - it's reason enough to reject mail. If it's there - you can see about who'll signed it. Read PGP documentation - there are a lot of information about trustpath and such. The fact is: with PGP you can change policy easily and you need only deal with 10-20 public signers while in case of SPF you're forced to trust god knows whom.
That much trouble? Posted Sep 7, 2004 12:19 UTC (Tue) by arafel (subscriber, #18557) [Link] >Argh. Of course receiving servers do not need to verify PGP signature - they>do not even need to check if it's there or not. End-user mail agent will do >it.
Then it doesn't accomplish what SPF is trying to do. A spammer I've annoyed before has used my domain as the 'source' for one of his spam floods. If SPF had been deployed, I wouldn't have received the 100,000 bounces or so that I got.
How do you propose that PGP signing of email would help with that? Because I can't see how it would make any real difference.
Bear in mind that the aim is to drop the mail before it even really enters the system, not to post process it. We can already do that.
>And as for "simple PGP signed (by unknown key) mail" being not better then
So all the spammers will do is use their zombie machines to generate keys and submit them to keyservers. Congratulations, we now have another wrecked resource.
That much trouble? Posted Sep 6, 2004 15:16 UTC (Mon) by jamesh (subscriber, #1159) [Link] None of the mail I receive is signed with my key either, I rarely correspond with myself. ;-) But more seriously, GPG/PGP's functionality indeed would not suffer at all if spammers used it, I'd still be able verify the authenticity of mail signed with a key which I have trustpath to. This is the point that I was trying to get across in my previous message :). A valid PGP signature on its own doesn't prove that a message is legitimate. All it does is prove that whoever sent the message holds the private key. You need something extra to prove that (the web of trust in the case of PGP). Similarly for SPF, a pass only proves that the mail came from a server approved by the domain holder. You would need to combine that fact with other information to determine if a message is legitimate. Both PGP and SPF help prevent third parties sending mail that claims to come from you though, which is their primary purpose (in PGP's case, one of its primary purposes). If you expect either to get rid of spam on their own, you will be disappointed.
POP and IMAP Posted Sep 6, 2004 2:16 UTC (Mon) by Ross (subscriber, #4065) [Link] One thing I never understood is why POP and IMAP never supporting sendingemail, only receiving it. If they had implemented a single protocol to handle both, which included user authentication, then most people wouldn't need an open SMTP server at their ISP to send email. This would have allowed more places to turn off unathenticated SMTP and we wouldn't have as much of a problem with SPAM from home user's systems (we would at least be able to track it down to the correct account).
Debian rejects Sender ID Posted Sep 5, 2004 19:59 UTC (Sun) by neoprene (guest, #8520) [Link] It seems like MS has finally woken up and smelled all the missed "opportunities" in the internet. Open Standards in The Internet and The PC architechture has led to nothing less than a technological revolution. Proprietary network services [I have a faint recollection of something called Compuserve ...] and proprietary hardware has had a tough time making a big breakthrough, likely because people are not as dumb as some corporate bean counters planned on. The internet came and caught MS with its pants down, their idea of a PC was a standalone appliance that could compete with Atari and Commodore-64. Networking was not part of the original vision and every attempt since has been a patch-up job to cover a faulty long term plan.The MS product is riddled with holes and one would think why they won't cover the basics like default security "ON" like no Administrator logins without at least severe warning boxes et cetera and also virus protection built-in. Instead MS is jumping on a weakness in the commonly used mail protocol to wedge control on the internet. This is a very bad idea that shows MS' poor grasp of reality, as usual.
Debian rejects Sender ID Posted Sep 5, 2004 23:48 UTC (Sun) by copsewood (subscriber, #199) [Link] Fine. Stick with classic SPF which has no such patent problem. M$ SenderID adds no value to this - it takes value away by bloating the SPF format with unneccessary XML, increasing the risk of exceeding the 500 byte DNS record threshold where you have to transition from UDP to TCP DNS lookup - making the whole thing unworkable. The reason some SPF developers have agreed to include SenderID in the proposed RFC is political, not technical, as this multiplies the clients likely to implement SPF/SenderID soon by a factor of 10. If my reading of the SPF list is correct, in practice, I think this standard proposal is likely to include classic SPF as the base implementation, and this is what will be used in practice as opposed to theory.
So why not use a callback instead? Posted Sep 6, 2004 7:10 UTC (Mon) by leonbrooks (guest, #1494) [Link]
Also, if the spammer is using an internet connection which bills them for traffic recieved, this starts to cost them. Especially if you're not charged for outbound traffic, and elect to respond to spam by portscanning the originating IP and sending back (say, for a DSL connection) 10000 copies of a 100kB randomised do-not-spam-me message for each inbound connection attempt from the spammer. If 1% of mail servers did this, the spammer would get back 100x the traffic that they send and would have no idea whether any of the portscans are for real. Since some spamming software chops the internet link when it sees an incoming portscan it will slow down their work tremendously and possibly increase the outlay too, and if they're running an auto-IP-blocking firewall the portscan causes the spammer's own firewall to protect you against them - and if they're not, your email server can tell you that, too.
So why not use a callback instead? Posted Sep 6, 2004 9:13 UTC (Mon) by lolando (subscriber, #7139) [Link] Assume I'm a spammer. Like my fellow spammers, I don't send e-mail from my own hosts but from open relays. I therefore register the whatever.com domain, host its name servers, and make its A/MX records point to some poor sod's open relay (that would be B by your notation, if I understood it correctly). Your A receives an email from my B (appearing to be from foo@whatever.com), double-checks everything, and proceeds to deliver it, or not (that will depend on how B is set up, I suppose). In any case, I have used very little of my own bandwidth.
Maybe I missed something.
So why not use a callback instead? Posted Sep 6, 2004 10:02 UTC (Mon) by frankie (subscriber, #13593) [Link] SPF-like protocols are not universal panacea. SPF just blocks forged addresses, like those used by a few spammers and worms.Many other spammers use fictious domains (with good SPF records) and pass anyway. The same thing could be done by worms potentially. So SPF complicates life of normal users (who cannot use regular forwarding) and have very little impact on true spammers who have methods to by pass it. I see no evidence that Sended-Id is better...
So why not use a callback instead? Posted Sep 6, 2004 10:58 UTC (Mon) by sdalley (subscriber, #18550) [Link] If by a fictitious domain you mean a domain that does not exist, then DNS lookup would not be able to obtain DNS records of any sort. Or do you actually mean something different?
Why no network of trust? Posted Sep 7, 2004 14:53 UTC (Tue) by forthy (guest, #1525) [Link] It is not obvious for me that you can't add a network of trust to aSPF-like framework. Like S/MIME or PGP, SPF records would need a signature (or several signatures, if you like). If you create your domain, the NIC usually would also sign your SPF record; done. Since domain creation is a hierarchical situation, tracing signatures back to some known good "root" signature is not really difficult. In the end, this does not help bot-based spam networks and worm floods. Even if you require the user to enter a passphrase for every outgoing mail, an infected PC could grab that passphrase and send spam and worms under the name of the victim. However: It is now possible to help the victim, since you can identify her (or him). Part of the success of captured computers is that the user doesn't know about it.
So why not use a callback instead? Posted Sep 6, 2004 10:25 UTC (Mon) by neilbrown (subscriber, #359) [Link] This is often referred to as "CBV" - call-back-verification.
The "from" address that is normally used is "<>". For other addresses it is possible to get false rejects.
The problem with this is that it allows an untraceable DOS attack. If some malcontent sent spam from thousands of "owned" machines all claiming to be from <axxx@my.domain>, then if all the recipients of that spam did CBV to my mailserver, it might be a very serious hit coming from genuine mail servers.
This may be a spectre rather than a real problem, and I'm seriously considering implementing it. However it doesn't really help stopped fakes or unwanted mail, at least not in the long run. It would server to keep the queue of outgoing bounces short though.
Debian rejects Sender ID - SMTP Authentification. Posted Sep 7, 2004 9:06 UTC (Tue) by philips (guest, #937) [Link] Posting off thread.I want to stress why authentication is important and sufficient. Spammers do pretend to send you something you do not want to receive. And you with you internet bandwidth do pay for spam. SMTP and Internet are designed so: we cannot use principle of post offices who charge sender for both sending and receiving. As I do understand current legal situation, someone cannot send me unsolicited e-mail. And the real problem that we cannot trace him - SMTP header is generally not authoritative and From: in particular. We cannot be sure who is responsible for sending given pile of crap. Have we authentication measures in - spammers will get "real names" on their e-mails. Police/whoever will be able to locate them and fix their brains. At moment - finding spammers by their IP addresses proved to be very difficult and burdensome process. As long as easy ways to access Internet are present (and actually we want more of them - like wi-fi) spammers will be able to change IP addresses even faster then before - making it even harder to trace them. Just because they can forge from: field. I'm ready to upgrade all my software to get rid off of spam. I'm not admin know - but in my times, when I was responsible for three domains and their mail, I absolutely sure that I will make a case to management to upgrade us to anti-spam loaded MTA. For our business partners we can make a sort of white-list - and ask them to upgrade. As business user, I have to publish my e-mail. I have to make it open - I cannot make white list - I have to receive e-mails from new partners I do not know about yet. We need a way to tell that guy who send this e-mail is the really who he claims to be. SMTP Authentication/SFP will not stop spam - but it will help hold spammers liable.
|
|||||||||||||