I got my parents a D-Tivo back when they were new. Got it directly from Tivo, in fact, before they actually hit shelves. Anyway, I also got the Lifetime Service for it.
I'd lose that Lifetime Service if I upgraded them to a Series 2 unit. Not a good option, as I dislike extra monthly fees, especially if they have to pay them. It was a gift, I don't like giving gifts that cost money.
Anyway, if my parents start experiencing the problem, I'll downgrade them to 3.1.0b, lock the software, and bypass the protections to disable the nag screen. Upgrading to a Series 2 is simply not an option, unless they can somehow keep the lifetime service on the new box.
As you know, the RealNetworks music store sells songs in 192 kbps AAC (as opposed to iTMS at 128 kbps). When transferring your purchased songs to the iPod, the AAC itself is not touched, but the Helix DRM is transmuxed to the DRM used by the iPod, i.e. fully protected and without trans-coding. If you then transfer the file back to your PC (for instance with Anapod), you get an M4P file, that is a protected MPEG-4 AAC file.
As you know, the RealNetworks music store sells songs in 192 kbps AAC (as opposed to iTMS at 128 kbps). When transferring your purchased songs to the iPod, the AAC itself is not touched, but the Helix DRM is transmuxed to the DRM used by the iPod, i.e. fully protected and without trans-coding. If you then transfer the file back to your PC (for instance with Anapod), you get an M4P file, that is a protected MPEG-4 AAC file.
Then Dan Collins posts this tidbit of info that might help somebody figure this one out:
I spent some time this morning trying to force the problem to occur, and finally was successful. The ONLY scenario that reproduced the problem on one of my Hughes Series 1 was as follows:
-A recording must be executing on at least one tuner -Signal quality must degrade to the point of causing severe digital artifacts WITHOUT a loss of signal lock -The poor signal quality must persist for at LEAST 15 seconds -The signal must then cut out completely on BOTH tuners -The recording must STILL be going on when signal is restored
I was NOT able to reproduce the problem when any one of these factors were missing. For example, if the recording ended before signal was restored - no problem. Or, if I just pulled the coax out of the receiver jacks and then reconnected - no problem.
The result was that, after meeting all of these conditions, on at least one of the tuners, after channel acquisition, the A/V would play normally for a second or three, then the video would freeze, while audio continues. Invoking the OSG, or pressing info would "unfreeze" the video for a second or two. This leads me to believe that it is NOT a problem with the state of the MPEG decoders, but rather a problem confined to the software itself.
So, this seems to be a rather specific set of conditions that must come together to cause this problem.
BTW: I reproduced the problem by installing variable resistors in the coax feeds and gradually increasing the resistance until signal lock was lost.
Maybe, if Fairplay were an open standard. But it isn't- it is a proprietary standard that Apple reserves the right to license to others and I see no basis for the legal system to NOT uphold this right.
You can't copyright a format. You simply can't do it. This one has been held up before by the courts a number of times. If someone wants to make their shit interoperable with your shit, *NOTHING* can stop them from doing so. Why? Because they simply have to add to their shit, and not to yours.
Furthermore, Fairplay has been fully reverse engineered by third parties who put up the documentation for free. And guess what? It uses the free to implement AES algorithim. With a bit of time and effort, any programmer worth his salt could create an encrypted AAC file and get the iPod to play it. It just isn't that damn hard to do when all the details are out there.
If someone desires this interoperability, there is a correct way to appoach it- they can license the technology.
As I recall, they did so, and Steve Jobs told them to go hang. Well, this is the result. As much as I dislike Real, more power to 'em. The more stuff that works with my iPod, the better.
Oh, one more thing.. We're all *assuming* that they are making something similar to the Fairplay DRM.. They don't have to be. Real's software could simply produce unprotected MPEG 4 Audio (M4A) files and load those onto the iPod. No DRM trickery needed whatsoever, and absolutely no basis for your argument if this is the way they do it.
Real sells AAC files using a slightly different DRM scheme. But the important thing here is how the iPod works for encrypted files.
Basically, it reads the AAC file to get a user identifier. This user ID is equated with a key stored in a file on the iPod itself. This user key allows it to decrypt the encrypted AAC file, which it then plays.
So if you have an encrypted AAC file (these use AES encryption, I believe), then all you have to do to get the iPod to play it is to a) put the key in the right place and b) suitably munge the AAC file so as to enable the iPod to work out which key it needs to use. Part A is simply a matter of putting the key into the right file, part B is messing with several key headers in the "M4P" file itself.
In other words, it's not particularly difficult to take an AES encrypted AAC file, to which you know the key, and munge the file to get it to play on the iPod without actually decrypting the thing and without transcoding.
That's if they wanted to preserve the file's encryption. If they didn't much care, they could just as easily decrypt the thing and write out an M4A file, unencrypted. The iPod could play that just fine too, without messing with the iPod keyring file.
From: me@alumni.address.edu Sender: alsome@yahoo.com is perfectly legitimate. If SPF breaks that, SPF is broken.
It's perfectly legitimate if you're actually sending mail from alumni.address.edu's servers.
Anyway, this isn't about the "From:" header int the message body. It's about the MAIL FROM header in the SMTP envelope. You can put any From: header in the message body that you want, but the SMTP envelope's MAIL FROM is what's being checked by SPF.
The problem is that a lot of systems assume that those two are the same address. They don't have to be, basically.
Well, it's possible to change the "From:" header in the address body without changing the Envelope MAIL FROM: command. SPF is checking the MAIL FROM: portion, not the message's From: header.
That is, Yahoo could conceivably connect to a server to send your email, use your yahoo.com email address as the MAIL FROM: line, and then a different address in the actual body of the message, and it'd make it through SPF, no trouble.
Virtually every SMTP receiver I have seen will show this happened to the sender by including a "Real-From:" header or something like that. But the email client almost always displays the given "From:" header instead. So it'll still be possible, usually, to spoof your From: header, you just won't be able to spoof the Envelope's from header. This really depends on how Yahoo does the spoof, actually. It might make it through SPF, but then it might not, depends on how they do it.
Except for the little fact that hell, you can come up with any scenario if you want. Nothing is perfect....And if the power dies, then you suddenly can't send email anymore...
Give me a break. First off, if you really have the need to send email from anywhere in the whole goddamn world, then you can still do so. "v=spl1 all". Yes, it lets anybody spoof you, but HTF is that any different from right now?
There is no perfect solution. This solution is good for 99% of the time, unless you contrive some crazy ass scenario that most people don't actually do and won't actually have a problem with. If you have special needs, then you can be accomodated at a cost.
And if it's that goddamn important for you to send email, you need to have your own secure server running on some obscure port somewhere where you can authenticate to it from where the hell you happen to be. You don't need to be using random ISP's SMTP servers and expecting all your mail to make it there unaffected.
Is there any mechanism in SPF (or Sender ID) for this email setup?
No, because you are basically forging email. Not that there's anything wrong with that, but it is what you are doing. You don't own alumni.xxx.edu, and they may not want you to send email (that purports to be from their systems) through Yahoo.
However, if you get the permission from the owners of alumni.xxx.edu, they might be okay with it and they might add yahoo to their SPF records.
But what you are doing is essentially the wrong way to do it, and that's what the Reply-to: header is for in the first place. You send email from yahoo as per usual, with a Reply-To: header saying where replies should be sent to. All email software supports this transparently, basically.
See, when a SPF-enabled receiver reads the DNS record, it's reading the DNS record for example.com. Since you control that, you can allow anything to send mail in the name of example.com that you want. The "include:" bit just tells it to use earthlink's SPF records (if they exist), and the "a:" bit tells it that anything from smtpserver.earthlink.com is allowed as well. The "-all" at the end disallows the rest of the world to send mail in the name of example.com.
The reason they haven't published SPF records yet is that they're working out how to tell all the hotmail users that they must start sending mail through hotmail and not through the users own ISP's servers. A lot of hotmail users do this, I'm sure.
OK- so if I have my own domain: example.com and I choose NOT to have an SPF record for that domain, I should be able to SEND emails out as per my post above and they "should" go through and not get rejected? The only reason I would WANT to publish an SPF would be to PREVENT a spammer from using example.com as a bogus FROM address?
Pretty much, yes. Although it's slightly more complicated than that.
If you don't publish an SPF record for your domain, then the receiving machine will have to fall back on whatever the default is. The default, however, is not defined. It can be accept the mail, reject the mail, accept the mail but flag it as possibly forged, accept the mail and add a "no SPF" weighing to whatever anti-spam algorithim it uses, etc. Basically, it depends on who you send it to.
Since there's not a heck of a lot of places using SPF yet, any likely defaults currently are to accept the mail. Once SPF is widely implemented, a lot of those might start flagging it as a possible forgery or maybe even simply rejecting it altogether. But that may never occur, basically.
The advantage to SPF is mainly when the sender has SPF records published and the receiver is reading and acting on them. In that event, it'll work all the way through. But you don't really see a lot of spam prevention benefit until SPF is very widely adopted and the defaults start to become something other than "accept it if there is no SPF record".
But you're right in that publishing a SPF record has absolutely no negative consequences and can only prevent spammers from forging your domain name to receivers using SPF records.
There's several ways DDNS services could implement this which make sense..
Assume they wanted their hosts to be able to send mail only from their own machines.. So the IP that is currently bob.example.com can send email from bob.example.com. They could add a TXT record to every DNS response like so: "v=spf1 a mx -all". This states that the receiver should lookup the A address of the domain it's looking up and see if it matches the IP of the sending box. It'll also lookup the MX record and allow that one as well.
Or the DynDNS provider might want to let you specify who your ISP is, and then let you send email from your ISP. In which case they could use: "v=spf1 include:your_isp.com -all", which would tell the receiver to lookup the SPF record for your ISP and use that as the valid senders.
Or they could simply add this and allow anybody to send email from that domain: "v=spf1 all".
In short, there's more to it than simply specifying addresses or ranges of addresses. It can be more complex and designed to handle most situations with minimal effort.
SRV records were, roughly speaking, meant for letting people add this sort of thing to DNS without having to add new record types. See also RFC2761, Extension Mechanisms for DNS. Yes. But SRV records are hard for people to understand, and TXT records are easy. Fast widespread adoption is our goal. The Right Thing To Do is to get our own RRtype, and we will apply for it. We just don't expect to get it anytime soon.
(for SRV records, see http://dqd.com/~mayoff/tools/djbdns/make-record.ad p)
If you control the domain that your email is from, then you simply need to change the DNS settings for that domain to add the proper SPF record.
Basically it's like this.. You have a domain like example.com. You send email from bob@example.com. But you want to send email through some other SMTP server, call it smtp.com, for whatever reason, and keep the From: line as bob@example.com. Since you control the domain, all you need to do is to change the DNS settings for your domain to add SPF records that say "smtp.com is a sender of email for example.com".
Problem solved. When a SPF enabled receiver gets your email, they query example.com's DNS, read the SPF info, see that it's okay for smtp.com to send email for that domain, and all is well.
Now, if you don't have access to your DNS records on that level, then I seriously suggest a) griping at your domain host/provider to let you have that sort of access, or b) switching to a new provider.
In the short term, however, this won't affect you at all. Not having an SPF record essentially means that the default will be used by SPF enabled receivers. The sane default, for the moment, is to allow email from anywhere in the event that SPF records do not exist on the domain in question (assuming SPF is being used as a straight block/no-block type of method, as opposed to a weighting factor in some spam prevention algorithim).
In the long term, eventually everybody will have to implement SPF if they want their email to be received by SPF enabled systems. But that's way, way long term.
If the problem is not really one of bandwidth but of server speed, then have your scripts update some static file instead of generating the thing on the fly. Have the server cache the static file in memory, and then it can serve it out nearly instantly.
If you have a PHP generating an RSS XML document every time anybody hits it, you're just begging to be DOS'd.
Everybody is griping about how PHP's license is incompatible with the GPL (meaning you cannot really use stuff under the PHP license with stuff under the GPL license together). So let's look it over, shall we?
Statements 1, 2, and 3 are extremely similar to the stuff you'll find in any and all BSD type licenses. They're basically straight rips from the BSD license, just reworded slightly. This is totally GPL compatible, as these are even less restrictive than the GPL is.
Statement 4 is similar to some parts of the GPL, but essentially it's just saying that they're retaining copyright and thus can change the license. As such, it's not particularly useful or informative, and I'd count it as a null factor. Especially since they cannot retroactively change a license, under any circumstances. This does not break GPL compatibility.
Statement 5 is the one that actually makes it GPL-incompatible, as the GPL states that you cannot place restrictions on the thing above and beyond the GPL itself. So if you derive something from GPL code and PHP-licensed code, it becomes essentially impossible to adhere to both licenses at once. You have to include a statement in your resulting license about this combined thing containing PHP code, while the GPL forbids you from placing that statement into the resulting combined license. Incompatible.
Statement 6 is interesting, because it states that the Zend section is separately licensed if you separate the thing from PHP or modify Zend itself. All this really states is that if you do mess with Zend, you need to rethink your licensing scheme. This may or may not be compatible with the GPL, depending on the resulting Zend license. However, it's most likely incompatible with the GPL, as it places an additional restriction on the use of the combined code that the GPL does not allow, namely that you have to relicense if you modify Zend itself.
Reconciliation: Statement 5 can be reconciled with the GPL easily: Remove it. That's the only way to make the PHP license compatible there.
Statement 6 is harder. The upshot here is that you'd have to remove it form the resulting combined license and separate Zend from PHP entirely, not distributing it at all. This could be problematic at best.
Upshot: Avoid using the PHP licensed code with GPL licensed code. Getting them to work together is essentially impossible. It's most likely easier to simply reinvent the wheel, on one side or the other.
Which is more "free": Depends on your definition of free.
-The GPL places one major restriction on you, namely that the resulting code and changes you make to GPL code is also available under the GPL itself.
-The PHP license places restriction 5 on you, which frankly ain't much, and restriction 6, which is a tough one to deal with if you do anything whatsoever to the Zend engine. Restriction 6 is most definitely bad, except that the vast majority of users of PHP licensed code won't be modifying the Zend engine and so it won't apply to them. It's probably one of the requirements for using Zend, and while it blows, it's not unworkable.
Which would I use: -If I used GPL code, I'm forced to use the GPL. -If I used PHP code, I'm not forced to do shit except put in a small one liner or something. -If I write my own code, I can do whatever I damn well please... And that's the important one here. I would personally not use nor emulate the PHP license, as it's really just a BSD license with some extra bits tossed in. I'd use a BSD license instead, if such was my intent (BSD basically puts it out there similar to being in the public domain, but with copyright retention, just in case). If I wanted the code to stay free forever, as in free for everybody to use and not free for anybody to steal, then I'd use the GPL.
Tivo can use a network connection
on
VoIP Questioned
·
· Score: 4, Interesting
If you get one of the newer boxes, plug a USB network dongle into the back of the thing, hook it up to your LAN, and use the proper codes and config and such, it can do the initial setup via the network. It's not obvious via the menus and such, I grant you, but it can be done.
Which is anyway beside the point, as a lot of the VoIP services have boxes available that you can plug a POTS phone into, some of which can handle modem traffic just fine.
None of your points are relevant. The original post was discussing the difference between Google and Microsoft in acquiring companies, not building products. Can you point to any actual evidence to refute it?
His points are totally relevant, and there doesn't need to be any evidence to refuse it because it's a simplistic view of the picture in the first place..
Simply "expanding" is neither good nor bad. We boo Microsoft not because they expand, but because of all the other bad shit that is done. And when the enemy gets bigger, I'd say you have a good reason to boo them.
Likewise, when the companies you like get bigger and offer free stuff because of it, well, I think a little props are in order. When was the last time Microsoft bought a company and paid them to make free software (free as in beer)?
There's nothing to refute because the point is stupid to begin with.
Sec. 121. - Limitations on exclusive rights: reproduction for blind or other people with disabilities
(a) Notwithstanding the provisions of section 106, it is not an infringement of copyright for an authorized entity to reproduce or to distribute copies or phonorecords of a previously published, nondramatic literary work if such copies or phonorecords are reproduced or distributed in specialized formats exclusively for use by blind or other persons with disabilities.
(b) (1) Copies or phonorecords to which this section applies shall -
(A) not be reproduced or distributed in a format other than a specialized format exclusively for use by blind or other persons with disabilities;
(B) bear a notice that any further reproduction or distribution in a format other than a specialized format is an infringement; and
(C) include a copyright notice identifying the copyright owner and the date of the original publication.
(2) The provisions of this subsection shall not apply to standardized, secure, or norm-referenced tests and related testing material, or to computer programs, except the portions thereof that are in conventional human language (including descriptions of pictorial works) and displayed to users in the ordinary course of using the computer programs.
(c) For purposes of this section, the term -
(1) ''authorized entity'' means a nonprofit organization or a governmental agency that has a primary mission to provide specialized services relating to training, education, or adaptive reading or information access needs of blind or other persons with disabilities;
(2) ''blind or other persons with disabilities'' means individuals who are eligible or who may qualify in accordance with the Act entitled ''An Act to provide books for the adult blind'', approved March 3, 1931 (2 U.S.C. 135a; 46 Stat. 1487) to receive books and other publications produced in specialized formats; and
(3) ''specialized formats'' means braille, audio, or digital text which is exclusively for use by blind or other persons with disabilities
Now, section (b)(1)(A) makes it hard to do this with webpages, and section (c)(1) requires that you be a nonprofit org. who does this sort of thing, but both problems could be worked around.
I disagree. The RIGHT way to do it is to have market competition.
I agree in principle. If Apple wants to do it their way, more power to 'em.
I was using "RIGHT" in the sense of "this is the way software developers should move to defeat this sort of hard to use criticism". When the interface is separate from the application, it's a lot easier to respond to user needs regarding making a simpler interface, vs. if the application's functionality is tightly tied to the interface.
You have a protocol between clients and servers.. and for any type of non-trivial program, you probably need a protocol between the UI and the program itself. It helps make for better code in general as well, as it forces you to consider the interface instead of just the functionality of the program.
I mean, if you consider the target market as "people who want to do things simply and don't do a lot of advanced stuff" then sure, I'd agree.
However, if you consider the target market as "people with portable digital music players and who want to buy music online" then I disagree. I'm certainly in that target market, but it doesn't fill all my needs and frankly I hate the design of iTunes in general. For me, personally, it makes the things I commonly want to do hard or impossible, and the things I nearly never do easy.
Or, if you want to define your target market as "people who like iTunes", which a lot of Apple users/defenders tend to do in a roundabout manner, then you have a bit of a useless definition, don't you?:)
See, the problem here is that iTunes works well if and only if you want to stick within its paradigm. If you want to use an iPod, buy from the iTMS, not play music with any other programs, rip CD's using iTunes ripper and encoder, and let only iTunes control and manage your music library, then it works great.
But: -If you have a different MP3 player (not an iPod), iTunes doesn't work with it. -If you buy from any other music store, iTunes won't read those files (allofmp3.com being an exception). -If you want to play music with any other programs, then you can't use the iTMS files because they have DRM (unless you work around this problem). -If you rip and encode using another program, iTunes CDDB (Gracenote) lookup features will not work on those songs. That only works when you use iTunes to rip the CD's. -If you move or rename songs using some other organization program, iTunes can't automatically scan for and find the new files, and if you manually scan a directory after you change it, you're left with duplicate entries in the iTunes library.
In other words, as long as you do what Apple thinks you want to do, it's great and easy. But different people do different things, and only supporting a very small subset of those things seems like a piss poor strategy. Yes, this may mean that you have to do some configuration in a program with support for more ways of working, but it also means you can work in the way you want to work instead of working in the way some company tells you that you should be working.
It's my computer, and I'll use it how I want to use it. For all Microsoft's flaws, they at least have some pretty vast configurability in their systems, even if it is hard to find and poorly described a lot of the time. Open source often tends to go a notch further and give you more or less complete control, but the cost for that is lots of configuration.
The RIGHT way to do this is to get the best of both worlds by separating the functionality from the interface. You write your program to support every configuration known to man, much the way open source tends to do. Then you build one more more interfaces on top of that, which abstracts it down to a much simpler set of configurations abilities, setting up defaults. The problem is that generally the interface and functionality are tied together very tightly, but if you separate them, you enable other programmers to develop their own interfaces to the actual guts of the program and thus simplify it for other users, if they want to do so. The only problem with this is that interface development tends to suck, so not a lot of people are doing it much.
Slashdot Mirror
I was not aware of that. Kick ass. I may be upgrading in the near future then, and possibly selling off the Series 1 box. :)
I got my parents a D-Tivo back when they were new. Got it directly from Tivo, in fact, before they actually hit shelves. Anyway, I also got the Lifetime Service for it.
I'd lose that Lifetime Service if I upgraded them to a Series 2 unit. Not a good option, as I dislike extra monthly fees, especially if they have to pay them. It was a gift, I don't like giving gifts that cost money.
Anyway, if my parents start experiencing the problem, I'll downgrade them to 3.1.0b, lock the software, and bypass the protections to disable the nag screen. Upgrading to a Series 2 is simply not an option, unless they can somehow keep the lifetime service on the new box.
Karl Lillevold, a Real Sr. Codec Engineer, has made this post over at hydrogenaudio.org: http://www.hydrogenaudio.org/forums/index.php?sho
Post is here.
Quoted post:
Then Dan Collins posts this tidbit of info that might help somebody figure this one out:
Maybe, if Fairplay were an open standard. But it isn't- it is a proprietary standard that Apple reserves the right to license to others and I see no basis for the legal system to NOT uphold this right.
You can't copyright a format. You simply can't do it. This one has been held up before by the courts a number of times. If someone wants to make their shit interoperable with your shit, *NOTHING* can stop them from doing so. Why? Because they simply have to add to their shit, and not to yours.
Furthermore, Fairplay has been fully reverse engineered by third parties who put up the documentation for free. And guess what? It uses the free to implement AES algorithim. With a bit of time and effort, any programmer worth his salt could create an encrypted AAC file and get the iPod to play it. It just isn't that damn hard to do when all the details are out there.
If someone desires this interoperability, there is a correct way to appoach it- they can license the technology.
As I recall, they did so, and Steve Jobs told them to go hang. Well, this is the result. As much as I dislike Real, more power to 'em. The more stuff that works with my iPod, the better.
Oh, one more thing.. We're all *assuming* that they are making something similar to the Fairplay DRM.. They don't have to be. Real's software could simply produce unprotected MPEG 4 Audio (M4A) files and load those onto the iPod. No DRM trickery needed whatsoever, and absolutely no basis for your argument if this is the way they do it.
Real sells AAC files using a slightly different DRM scheme. But the important thing here is how the iPod works for encrypted files.
Basically, it reads the AAC file to get a user identifier. This user ID is equated with a key stored in a file on the iPod itself. This user key allows it to decrypt the encrypted AAC file, which it then plays.
So if you have an encrypted AAC file (these use AES encryption, I believe), then all you have to do to get the iPod to play it is to a) put the key in the right place and b) suitably munge the AAC file so as to enable the iPod to work out which key it needs to use. Part A is simply a matter of putting the key into the right file, part B is messing with several key headers in the "M4P" file itself.
In other words, it's not particularly difficult to take an AES encrypted AAC file, to which you know the key, and munge the file to get it to play on the iPod without actually decrypting the thing and without transcoding.
That's if they wanted to preserve the file's encryption. If they didn't much care, they could just as easily decrypt the thing and write out an M4A file, unencrypted. The iPod could play that just fine too, without messing with the iPod keyring file.
From: me@alumni.address.edu
Sender: alsome@yahoo.com
is perfectly legitimate. If SPF breaks that, SPF is broken.
It's perfectly legitimate if you're actually sending mail from alumni.address.edu's servers.
Anyway, this isn't about the "From:" header int the message body. It's about the MAIL FROM header in the SMTP envelope. You can put any From: header in the message body that you want, but the SMTP envelope's MAIL FROM is what's being checked by SPF.
The problem is that a lot of systems assume that those two are the same address. They don't have to be, basically.
Well, it's possible to change the "From:" header in the address body without changing the Envelope MAIL FROM: command. SPF is checking the MAIL FROM: portion, not the message's From: header.
That is, Yahoo could conceivably connect to a server to send your email, use your yahoo.com email address as the MAIL FROM: line, and then a different address in the actual body of the message, and it'd make it through SPF, no trouble.
Virtually every SMTP receiver I have seen will show this happened to the sender by including a "Real-From:" header or something like that. But the email client almost always displays the given "From:" header instead. So it'll still be possible, usually, to spoof your From: header, you just won't be able to spoof the Envelope's from header. This really depends on how Yahoo does the spoof, actually. It might make it through SPF, but then it might not, depends on how they do it.
Except for the little fact that hell, you can come up with any scenario if you want. Nothing is perfect. ...And if the power dies, then you suddenly can't send email anymore...
Give me a break. First off, if you really have the need to send email from anywhere in the whole goddamn world, then you can still do so. "v=spl1 all". Yes, it lets anybody spoof you, but HTF is that any different from right now?
There is no perfect solution. This solution is good for 99% of the time, unless you contrive some crazy ass scenario that most people don't actually do and won't actually have a problem with. If you have special needs, then you can be accomodated at a cost.
And if it's that goddamn important for you to send email, you need to have your own secure server running on some obscure port somewhere where you can authenticate to it from where the hell you happen to be. You don't need to be using random ISP's SMTP servers and expecting all your mail to make it there unaffected.
Is there any mechanism in SPF (or Sender ID) for this email setup?
No, because you are basically forging email. Not that there's anything wrong with that, but it is what you are doing. You don't own alumni.xxx.edu, and they may not want you to send email (that purports to be from their systems) through Yahoo.
However, if you get the permission from the owners of alumni.xxx.edu, they might be okay with it and they might add yahoo to their SPF records.
But what you are doing is essentially the wrong way to do it, and that's what the Reply-to: header is for in the first place. You send email from yahoo as per usual, with a Reply-To: header saying where replies should be sent to. All email software supports this transparently, basically.
Not if you control the DNS for example.com.
You need to add a TXT record to your example.com domain's DNS. It should look like this (or similar in some fashion):
"v=spf1 include:earthlink.com a:your smtpserver.earthlink.com -all"
See, when a SPF-enabled receiver reads the DNS record, it's reading the DNS record for example.com. Since you control that, you can allow anything to send mail in the name of example.com that you want. The "include:" bit just tells it to use earthlink's SPF records (if they exist), and the "a:" bit tells it that anything from smtpserver.earthlink.com is allowed as well. The "-all" at the end disallows the rest of the world to send mail in the name of example.com.
Simple. Take a read about it here: http://spf.pobox.com.
The reason they haven't published SPF records yet is that they're working out how to tell all the hotmail users that they must start sending mail through hotmail and not through the users own ISP's servers. A lot of hotmail users do this, I'm sure.
OK- so if I have my own domain:
example.com
and I choose NOT to have an SPF record for that domain, I should be able to SEND emails out as per my post above and they "should" go through and not get rejected?
The only reason I would WANT to publish an SPF would be to PREVENT a spammer from using example.com as a bogus FROM address?
Pretty much, yes. Although it's slightly more complicated than that.
If you don't publish an SPF record for your domain, then the receiving machine will have to fall back on whatever the default is. The default, however, is not defined. It can be accept the mail, reject the mail, accept the mail but flag it as possibly forged, accept the mail and add a "no SPF" weighing to whatever anti-spam algorithim it uses, etc. Basically, it depends on who you send it to.
Since there's not a heck of a lot of places using SPF yet, any likely defaults currently are to accept the mail. Once SPF is widely implemented, a lot of those might start flagging it as a possible forgery or maybe even simply rejecting it altogether. But that may never occur, basically.
The advantage to SPF is mainly when the sender has SPF records published and the receiver is reading and acting on them. In that event, it'll work all the way through. But you don't really see a lot of spam prevention benefit until SPF is very widely adopted and the defaults start to become something other than "accept it if there is no SPF record".
But you're right in that publishing a SPF record has absolutely no negative consequences and can only prevent spammers from forging your domain name to receivers using SPF records.
There's several ways DDNS services could implement this which make sense..
Assume they wanted their hosts to be able to send mail only from their own machines.. So the IP that is currently bob.example.com can send email from bob.example.com. They could add a TXT record to every DNS response like so: "v=spf1 a mx -all". This states that the receiver should lookup the A address of the domain it's looking up and see if it matches the IP of the sending box. It'll also lookup the MX record and allow that one as well.
Or the DynDNS provider might want to let you specify who your ISP is, and then let you send email from your ISP. In which case they could use: "v=spf1 include:your_isp.com -all", which would tell the receiver to lookup the SPF record for your ISP and use that as the valid senders.
Or they could simply add this and allow anybody to send email from that domain: "v=spf1 all".
In short, there's more to it than simply specifying addresses or ranges of addresses. It can be more complex and designed to handle most situations with minimal effort.
Shouldn't you use SRV or EDNS0 records?
SRV records were, roughly speaking, meant for letting people add this sort of thing to DNS without having to add new record types. See also RFC2761, Extension Mechanisms for DNS.
Yes. But SRV records are hard for people to understand, and TXT records are easy. Fast widespread adoption is our goal. The Right Thing To Do is to get our own RRtype, and we will apply for it. We just don't expect to get it anytime soon.
(for SRV records, see http://dqd.com/~mayoff/tools/djbdns/make-record.a
If you control the domain that your email is from, then you simply need to change the DNS settings for that domain to add the proper SPF record.
Basically it's like this.. You have a domain like example.com. You send email from bob@example.com. But you want to send email through some other SMTP server, call it smtp.com, for whatever reason, and keep the From: line as bob@example.com. Since you control the domain, all you need to do is to change the DNS settings for your domain to add SPF records that say "smtp.com is a sender of email for example.com".
Problem solved. When a SPF enabled receiver gets your email, they query example.com's DNS, read the SPF info, see that it's okay for smtp.com to send email for that domain, and all is well.
Now, if you don't have access to your DNS records on that level, then I seriously suggest a) griping at your domain host/provider to let you have that sort of access, or b) switching to a new provider.
In the short term, however, this won't affect you at all. Not having an SPF record essentially means that the default will be used by SPF enabled receivers. The sane default, for the moment, is to allow email from anywhere in the event that SPF records do not exist on the domain in question (assuming SPF is being used as a straight block/no-block type of method, as opposed to a weighting factor in some spam prevention algorithim).
In the long term, eventually everybody will have to implement SPF if they want their email to be received by SPF enabled systems. But that's way, way long term.
If the problem is not really one of bandwidth but of server speed, then have your scripts update some static file instead of generating the thing on the fly. Have the server cache the static file in memory, and then it can serve it out nearly instantly.
If you have a PHP generating an RSS XML document every time anybody hits it, you're just begging to be DOS'd.
Everybody is griping about how PHP's license is incompatible with the GPL (meaning you cannot really use stuff under the PHP license with stuff under the GPL license together). So let's look it over, shall we?
Statements 1, 2, and 3 are extremely similar to the stuff you'll find in any and all BSD type licenses. They're basically straight rips from the BSD license, just reworded slightly. This is totally GPL compatible, as these are even less restrictive than the GPL is.
Statement 4 is similar to some parts of the GPL, but essentially it's just saying that they're retaining copyright and thus can change the license. As such, it's not particularly useful or informative, and I'd count it as a null factor. Especially since they cannot retroactively change a license, under any circumstances. This does not break GPL compatibility.
Statement 5 is the one that actually makes it GPL-incompatible, as the GPL states that you cannot place restrictions on the thing above and beyond the GPL itself. So if you derive something from GPL code and PHP-licensed code, it becomes essentially impossible to adhere to both licenses at once. You have to include a statement in your resulting license about this combined thing containing PHP code, while the GPL forbids you from placing that statement into the resulting combined license. Incompatible.
Statement 6 is interesting, because it states that the Zend section is separately licensed if you separate the thing from PHP or modify Zend itself. All this really states is that if you do mess with Zend, you need to rethink your licensing scheme. This may or may not be compatible with the GPL, depending on the resulting Zend license. However, it's most likely incompatible with the GPL, as it places an additional restriction on the use of the combined code that the GPL does not allow, namely that you have to relicense if you modify Zend itself.
Reconciliation:
Statement 5 can be reconciled with the GPL easily: Remove it. That's the only way to make the PHP license compatible there.
Statement 6 is harder. The upshot here is that you'd have to remove it form the resulting combined license and separate Zend from PHP entirely, not distributing it at all. This could be problematic at best.
Upshot:
Avoid using the PHP licensed code with GPL licensed code. Getting them to work together is essentially impossible. It's most likely easier to simply reinvent the wheel, on one side or the other.
Which is more "free":
Depends on your definition of free.
-The GPL places one major restriction on you, namely that the resulting code and changes you make to GPL code is also available under the GPL itself.
-The PHP license places restriction 5 on you, which frankly ain't much, and restriction 6, which is a tough one to deal with if you do anything whatsoever to the Zend engine. Restriction 6 is most definitely bad, except that the vast majority of users of PHP licensed code won't be modifying the Zend engine and so it won't apply to them. It's probably one of the requirements for using Zend, and while it blows, it's not unworkable.
Which would I use:
-If I used GPL code, I'm forced to use the GPL.
-If I used PHP code, I'm not forced to do shit except put in a small one liner or something.
-If I write my own code, I can do whatever I damn well please... And that's the important one here. I would personally not use nor emulate the PHP license, as it's really just a BSD license with some extra bits tossed in. I'd use a BSD license instead, if such was my intent (BSD basically puts it out there similar to being in the public domain, but with copyright retention, just in case). If I wanted the code to stay free forever, as in free for everybody to use and not free for anybody to steal, then I'd use the GPL.
If you get one of the newer boxes, plug a USB network dongle into the back of the thing, hook it up to your LAN, and use the proper codes and config and such, it can do the initial setup via the network. It's not obvious via the menus and such, I grant you, but it can be done.
Which is anyway beside the point, as a lot of the VoIP services have boxes available that you can plug a POTS phone into, some of which can handle modem traffic just fine.
None of your points are relevant. The original post was discussing the difference between Google and Microsoft in acquiring companies, not building products. Can you point to any actual evidence to refute it?
His points are totally relevant, and there doesn't need to be any evidence to refuse it because it's a simplistic view of the picture in the first place..
Simply "expanding" is neither good nor bad. We boo Microsoft not because they expand, but because of all the other bad shit that is done. And when the enemy gets bigger, I'd say you have a good reason to boo them.
Likewise, when the companies you like get bigger and offer free stuff because of it, well, I think a little props are in order. When was the last time Microsoft bought a company and paid them to make free software (free as in beer)?
There's nothing to refute because the point is stupid to begin with.
http://www4.law.cornell.edu/uscode/17/121.html
Now, section (b)(1)(A) makes it hard to do this with webpages, and section (c)(1) requires that you be a nonprofit org. who does this sort of thing, but both problems could be worked around.
I disagree. The RIGHT way to do it is to have market competition.
I agree in principle. If Apple wants to do it their way, more power to 'em.
I was using "RIGHT" in the sense of "this is the way software developers should move to defeat this sort of hard to use criticism". When the interface is separate from the application, it's a lot easier to respond to user needs regarding making a simpler interface, vs. if the application's functionality is tightly tied to the interface.
You have a protocol between clients and servers.. and for any type of non-trivial program, you probably need a protocol between the UI and the program itself. It helps make for better code in general as well, as it forces you to consider the interface instead of just the functionality of the program.
I mean, if you consider the target market as "people who want to do things simply and don't do a lot of advanced stuff" then sure, I'd agree.
:)
However, if you consider the target market as "people with portable digital music players and who want to buy music online" then I disagree. I'm certainly in that target market, but it doesn't fill all my needs and frankly I hate the design of iTunes in general. For me, personally, it makes the things I commonly want to do hard or impossible, and the things I nearly never do easy.
Or, if you want to define your target market as "people who like iTunes", which a lot of Apple users/defenders tend to do in a roundabout manner, then you have a bit of a useless definition, don't you?
See, the problem here is that iTunes works well if and only if you want to stick within its paradigm. If you want to use an iPod, buy from the iTMS, not play music with any other programs, rip CD's using iTunes ripper and encoder, and let only iTunes control and manage your music library, then it works great.
But:
-If you have a different MP3 player (not an iPod), iTunes doesn't work with it.
-If you buy from any other music store, iTunes won't read those files (allofmp3.com being an exception).
-If you want to play music with any other programs, then you can't use the iTMS files because they have DRM (unless you work around this problem).
-If you rip and encode using another program, iTunes CDDB (Gracenote) lookup features will not work on those songs. That only works when you use iTunes to rip the CD's.
-If you move or rename songs using some other organization program, iTunes can't automatically scan for and find the new files, and if you manually scan a directory after you change it, you're left with duplicate entries in the iTunes library.
In other words, as long as you do what Apple thinks you want to do, it's great and easy. But different people do different things, and only supporting a very small subset of those things seems like a piss poor strategy. Yes, this may mean that you have to do some configuration in a program with support for more ways of working, but it also means you can work in the way you want to work instead of working in the way some company tells you that you should be working.
It's my computer, and I'll use it how I want to use it. For all Microsoft's flaws, they at least have some pretty vast configurability in their systems, even if it is hard to find and poorly described a lot of the time. Open source often tends to go a notch further and give you more or less complete control, but the cost for that is lots of configuration.
The RIGHT way to do this is to get the best of both worlds by separating the functionality from the interface. You write your program to support every configuration known to man, much the way open source tends to do. Then you build one more more interfaces on top of that, which abstracts it down to a much simpler set of configurations abilities, setting up defaults. The problem is that generally the interface and functionality are tied together very tightly, but if you separate them, you enable other programmers to develop their own interfaces to the actual guts of the program and thus simplify it for other users, if they want to do so. The only problem with this is that interface development tends to suck, so not a lot of people are doing it much.