Re:They needed three days to figure this out?
on
Spam Meeting Wrap-up
·
· Score: 1
reject_unverified_sender works like this:
mail arrives from sender@example.com for victim@localdomain.com
Before allowing the dialog to progress past RCPT FROM, postfix attempts to send mail to sender@example.com. The mail connection is never completed -- just the MAIL FROM and RCPT TO are attempted, so sender@example.com never receives any email as a result of this probe. (postmaster might note a log entry for NULL connection...whatever).
...
Ugh, I hope it doesn't work like that. It would cause horrible loop problems - imagine that the sender is also using this patch. The recipient server would open a connection to the sender to verify the address. The sender would open a connection to the recipient to verify it, since at the point the verification happens it's unable to distinguish actual mail sending from this verification. So it's an endless loop between the two, consuming more and more CPU time and bandwidth for a Postfix shouting match.
If your description is accurate, this patch should never be used.
Unfortunately they've been dumbing down the high school chemistry books to make sure students can't figure out how to from those books. They've ruined chemistry classes in the pathetic attempt to prevent students from learning "bad things".
Do you have anything at all to back up that statement? Specific examples, maybe?
Not that it's such a big deal, I imagine any affected Windows versions of IE can be relaunched and people will just avoid going to places with such code. I fail to see the significance.
If this is just a denial of service attack, you're probably right. But it's often the case that when you can crash software, you can insert arbitrary code. (Buffer overflows, format string vulnerabilities...the most common causes of segfaults.) So what makes this really worrisome is not the inconvenience of restarting the browser but the fear that any website you go to can completely compromise your machine.
Interestingly too, the resistor slowed Zalman casefans are far louder than the Enermax PSU fans. Does anyone know if I dare reduce the voltage on the case fans even more?
You might try Silencer fans instead. No fan is truly silent, but these are 20dB. IIRC, whispers are 30dB, so you might not even be able to hear it at all. Mine does not contribute tto my machine's noise in any noticeable way. I've also got a Silencer power supply. That just leaves the processor and video card fans.
SPAMmers will still find ways to subvert individual's legitimate accounts. This does and will partially negate any benefits of distinctly identifying sender(s).
To add a bit more to my reply: they definitely do this now, very easily. If the certificates were required, they probably still would occasionally, but with much more difficulty. They couldn't just send it claiming to be that person and be believed. They'd have to get it sent with the certificate, presumably by breaking into that person's computer or a computer of the ISP which issued it.
This is all assuming this hypothetical system is fully adopted, of course. At best there's like a 10-year interim period, during which unsigned emails become progressively less trusted.
I don't view loss of anonymity on the internet/over SMTP as a "Bad Thing (tm)." If absolutely everyone that connected to the internet were uniquely, traceably identified I think people would use the internet/e-mail a lot more responsibly.
I would view complete loss of anonymity as a bad thing. As my last post said, I think it will work out that people can be fairly anonymous (someone trustworthy running an aonymous remailer issues a certificate for an address, not knowing who they issued it to or just not being willing to say). So you can take on a specific anonymous identity. (You can do that now, but it's not mainstream. Not many people know about PGP.)
SPAMmers will still find ways to subvert individual's legitimate accounts. This does and will partially negate any benefits of distinctly identifying sender(s).
Agreed. But it's still an improvement. If you don't know who they are, you're doomed in the blocking them.
SPAM-filter *corporations* in the meantime benefit by adding more spam to the mix (themselves!) I find myself unable to trust any company that says it has an e-mail solution. I tend to theorize that they are at least subsidizing third party SPAMmers (indirectly or directly.)
I don't know; I tend to trust in the solution, not the person who presents it.
Certificate vendors are also suspect whenever a proposal arises that implies that all individuals need certificates. The article wasn't talking about using ssh-keygen or PGP. It was suggesting a paid CA issuing individuals certificates (or did I read too much into that?)
Yeah, I think the author was suggesting that. I wouldn't want everyone to pay Verisign either, which is why I suggested the alternative. It'd still allow the benefits of everyone having certificates without many of the problems of that scheme.
spam can not be stopped. period. if you believe otherwise you are misguided. the protocol does its jobs, and the verification of the headers and contect are to be done on the end systems. a challenge system at the backbone level is ignorant.
Verifying the headers at the end just doesn't work very well. Interpreting even the "Received:" headers is electronic hearsay. "Server A said that Server B said that Server C said that..." The only way I see to solve this is for each server to digitally sign what it sends to the next.
SMTP has various facilities for digital signatures: S/MIME for end content (though I think it's body text only; headers (notably subject) are sent in the clear). SSL-level certs (to verify the transport is secure). SMTP AUTH (to authenticate a user to a server that knows that user; their mail exchange). But none of them can solve even the problem of verifying Received: headers.
What's really needed is something that essentially treats these as a set of envelopes, each containing the last (and thus all the envelopes it contains). The innermost would be made by the user, the inside encrypted, and both the inside/outside (outside holding sender/recipient information) signed. The first server wraps it in its own envelope, signs it, and sends it to the next. And so on. You can skip the hearsay if you can verify signatures. When the final user opens it, the last link in the chain must be a UI that makes it really easy to understand the security implications with a "Verify" button or something.
Of course, all these certificates would require a decent PKI system. Everyone paying Verisign is just not going to work. As I mentioned in another post, I think the ideal would be to implement SecureDNS. Top-level domains issue certificates to second-level, etc. The MXs issue them to their users. So you can grab someone's public key quite easily and verify it. Plus, it's still possible to have relative anonymity, if you can talk "anonserver.com" into issuing you a certificate as "Anonymous Person 42" or whatever.
Having all the Received: headers verifiable means you can see the path a message took. It might also be beneficial to have a way of determining a reasonable path for a message to take, to avoid problems with open relays. (Though they're not as big anymore, since you can reliably tell where the message came from to begin with.) It's too late for me to think a lot about this problem, but I think using the DNS system for a domain to say what MXs may send mail to the world from it is a reasonable approach.
So it's kind of a complicated system, but I think this would let you have a lot more accountability. You could find out who sent a message or the last person who is not willing to tell you whom they issued a certificate to. If there's an excessive amount of spam from that place, block them. You just can't do that now - there's no good way of telling where a message came from.
Also, the idea of individuals having certificates was pretty funny. Good way to increase certificate sales without addressing the underlying SPAM problem at all.
I complete disagree with that:
First, spam is not the only important problem with SMTP. There's also identity theft. I just finished reading this article about email identity theft on CNN. When a technology problem hits CNN, you know it's not rare. If people expected email to be digitally signed, this would not have happened.
Second, individuals having certificates does not necessarily mean individuals buying certificates from Verisign. I'd imagine each MX issuing certificates to users. The MX's signature is fetched from DNS and verified against each successive higher domain until it gets to the TLD. (There is a DNS standard for this, called "SecureDNS" or something creative like that. Unfortunately, the TLDs aren't issuing certificates yet, so no one can really use it.)
Third, I believe certificates would reduce the spam problem to some extent. Every spam I get has forged headers in some way. It's hard to see where it actually came from...a mail server can just make up Received: lines behind it; you don't know if it was relaying or lieing. If servers embedded digital signatures, it'd make a big difference. Now, individual email addresses? Still yes, to a certain extent. People tend to reply to spams at the address they are sent from...which of course is bogus; nonexistant or someone else's. If they can't send a message from an account without a signature, the account has to exist and be theirs. (Or the server is theirs, or whatever. You have to think a bit about exactly who issued every certificate, but even a complex system of trust is better than none.) More accountability means it's easier to track down undesirable users of the system.
I'd also like point out (and here I'm not refuting the parent post) that I don't think the certificate thing means losing anonymity completely. There will always be someone willing to run an anonymous email server. They'll hand out certificates so you know you're talking to the same anonymous person each time. (That's good.) They may know the identity, but no one else will. If they're in a place like Seahaven, they can't be subpoenad to reveal it. If it's abused and spam is sent from there, people simply won't accept emails from that anonymous server anymore.
That was my thinking, too. That sort of "recharge" has been available in wrist watches for some time (no winding necessary, your wrist movements do it). For a cell phone with small power needs, it would seem a simple thing to accomplish.
Cell phones use dramatically more energy than wrist watches. While on standby, power (energy use / time) should probably be comparable to a watch's[*]. But the transmitter uses much more power than a small processor and LCD. That's why cell phone battery capacity is often measured in N hours/days of standby or N minutes/hours of talk time.
I think neither method would gather enough energy to justify additional complexity in the cell phone.
[*] but it clearly isn't, as a tiny watch battery can power a watch for years, and a much larger cell phone battery can power one for a couple days at best. Anyone know what else the cell phone is doing while on standby? Does it transmit occasionally to ping the tower or something?
Such a system will probably be initially implemented for long-range sniper teams. Such a team using this particular weapon could move into an abandoned house nearly 3 times as far away as current sniper rifle's maximum range, could fire more quietly, and hopefully would have the distance and confusion to get away.
You're probably right. Not only that, but it'd probably be easier than present sniper rifles. They're firing from far enough away that with conventional weapons they have to lead the target, compensate for wind, etc. With a laser weapon, you'd just point where they are now. Light's a bit faster than bullets.
the efficiency of a chain is no better than the efficiency of the weakest link.
True, but not the strongest statement you could make. The efficiency of a chain is the efficiencies of each link multiplied together. That's much worse than just as bad as the weakest.
That's why I don't buy your original argument. You were comparing two efficiencies that just aren't comparable: that 90% has to be multiplied by something else, and that something else will also be under 100%. Just adding steps will always make the efficiency worse.
Studies into end-to-end efficiencies of EV vs ICE are available [princeton.edu].
Yes, that study is interesting. From it, I'm sold that the electrical vehicles are both cleaner and more efficient as a practical matter. But that seems to be because the larger plants are dramatically cleaner and more efficient. If they were both the maximum theoretical (with the same cycle and temperatures), which was the number you originally mentioned, the electrical one would have to be worse.
The other 32% of energy sources the study mentioned are always interesting, but there are reasons they are only 32%... maybe some day.
So basically, I'm not disagreeing with your conclusion. But that doesn't make your logic valid. The study was convincing; your original post was not.
True, heat engines will never get better than 60%. However motors already get the high 90 percent efficiencies. This is yet another reason why cars should move away from engines.
I don't buy that argument. Motors convert electrical energy to kinetic energy. Where does the electrical energy come from? Typically a heat engine and generator. 60% * x% * 90% is less than 60%.
I would be most greatful for any help proving me wrong.
Looking at that list, most of your stuff deals with sendmail's virtusertable. Postfix's virtual map does the same thing. The only thing I don't know that it supports is domain mirroring, but you could accomplish that by preprocessing the virtual file a bit.
The alias file format is the same as sendmail's. (Well, not quite true; it supports two file formats; one is the same.) Everything you can do with sendmail you can do there, though you need to keep in mind that it happens as user Postfix.
The other stuff, you just need to go through the documentation more thoroughly. It'd be a waste of my time and yours to give a not-quite-as-good version of what it says. But Postfix can do those things.
Yes but qmail and postfix dont do near as much as sendmail.
Care to provide examples? I've never seen anyone actually come up with a useful thing you can do with sendmail but not postfix, for all the times people have said this.
Hell, even if you do have to patch Postfix's C source, it's probably still easier than doing whatever in sendmail's m4-preprocessed cf files. I have written a patch to Postfix, and it was not difficult.
Has RedHat gone insane? Do they not realize people count on linux in an enterprise environment, where anything beyond a few minutes downtime is very bad?
No, they figure that anyone doing that can afford the $349 for the basic version of RedHat Enterprise Linux ES, which has a guaranteed five-year lifetime.
This page is kind of a shock to me, too[*], but they aren't abandoning enterprise people at all.
[*] - this is surprising in at least three ways:
They've never preannounced releases before
They've never not had a.1 release
They've only changed major numbers with binary incompatibility - I'm not sure what would be incompatible here. Maybe the new threading stuff in glibc.
So in reality "Opting out" often will only bring you MORE spam, not less.
Yes, when I get random emails claiming to be opt-out lists or that I opted in, I also don't opt out for this reason.
But this is a different situation. He opted in to a list with Audiogalaxy. A relatively reputable place, and they already knew his email address was valid because he opted in. It was a reasonable thing to do, and the spam should stop afteward. But judge apparently felt it was not practical for them to have distributed that notification to all their partners in two days, so he threw out the lawsuit. Presumably it takes them that long to distribute opt-ins also.
I hadn't seen this before. It's interesting, but I don't think I like this reversal for several reasons:
I don't like giving the sender that much information about where I'm reading my mail from, when I'm reading it, etc. If I connect to their server when I want the whole message, I have to. Unless I automatically pull everything right away to my server...but then it's not really a pull model, just an overly complicated push.
This is a big fat lie: "In IM2000, the receiver's ISP can keep notifications in memory." If the notification is lost, the message itself might as well be unless you check that store frequently. The only situation in which I could actually see that being true is something like a mailing list where it's extremely likely I'll get another message soon from the same place.
With the old systems, once the sender sends a message, it can't be changed unless they also control the receiver's system. I like that. Here they can change it up until the point the receiver actually fetches the message. Even afterward unless the receiver caches it locally, so I think receivers always will.
It's only marginally true that people can only fetch messages if they aren't interested in them. If they know based on the store that they aren't interested, sure. But to really know you aren't interested, likely you need to see more information than the simple notification that a message is available. At least the headers will need to be sent.
It doesn't answer the question of how the receiver should authenticate to the sender when pulling the message. That's an important one.
Really, the only problem I really see this absolutely solving is the mailing list one. I'm not willing to abandon a favorable model for everything else just so mailing lists are better. They can either cope or use a separate protocol without dragging everything else along with them.
I'm much more in favor of a new, authenticated push protocol. I think much of the spam problem could be eased by a more reliable way of knowing who sent a message.
User access systems are one of the bits of web applications which always cause me lots of grief - especially when you have users with differing levels of access to various parts of the system/features/whatever. Debugging things like that is a nightmare
Agreed. There are all sorts of reasons it would be useful to log in as another user with your own credentials instead of (or in addition to) having global administrator privileges.
I even ran into an application that failed depending on your username. They'd made an audit field in an Oracle database, but didn't make it the full 30 characters long an identifier can be. So when I logged in as "LAMBS" it worked, but "MEDICINE\LAMBS" failed. That sort of thing is all but impossible to debug unless you can log in as the person experiencing the problem.
Wouldn't the better option be to make your application expire a certain number of days after installation UNLESS a code is entered? The theory being that when you recive payment, you provide the code.
I don't like it. What if they have to reinstall, well after the contract is over and they've paid? It will spontaneously break N days later, and they'll be (legitimately) quite pissed off.
I have a overriding password that bypasses the standard authentication system and lets the admin user assume the username/authentication details of an arbitrary user. That's important so I can have the same experience as that user.
This is something I wish more systems had, but not in a hardcoded (backdoor) way. Cyrus SASL/IMAPd does it correctly: they've completely separated the concepts of authentication and authorization. So you can say "until further notice, user slamb can log in and do anything user bob can do." It serves the same purpose, but in a maintainable, open way. You can have a group of administrators that can log in as anyone, but without needing to know either everyone's password or some master password that's difficult to change if someone leaves...they can just use their own, and it can be disabled/enabled on a per-person easily.
> > I'm sure the more 'vocal' conservationalists have one opinion.
> What exactly is that supposed to mean?
> That a government run by sociopaths who have turned China into one of the most polluted countries on earth might not be the best people in charge of drilling holes into the moon?
What, do you think they're going to make it completely inhospitable to terrestrial life? Because I've got news for you: there's no ecology there to maintain. They can't screw it up.
If you just want to be bloody-minded and argue against it, there are other choices:
It's not owned by any nation. So what right do they have to use it? (There is a precedent here with newly discovered lands within our own planet, however.)
It's not economically feasible. (Wouldn't be surprised if that's the case...flying rockets around is rather expensive, you know.)
My prefered way to do it is, get something like the Promise UltraTrak SX8000, and put 8 200Gb IDE drives in it.. If you do RAID0, that'll give you 1.6Tb.. If you do RAID5, it'll give you 1.4Tb
Ugh! Don't do RAID0 with 8 drives! With RAID0, losing a single drive means the whole array is all but worthless. (Hard to get data off with one in eight chunks missing...) I think the longevity of a single drive is a normal distribution with a mean at its MTBF. If I remember my statistics, that means the combined MTBF is just the MTBF of a single one divided by eight. Don't divide your reliability by eight!
The RAID5 is a much better solution, since it can handle a single drive failure with no problems. The odds of two drives failing at the same time are really low. So as long as you are prompt about replacing failed drives, you can't go wrong.
No, it wasn't clear to me. I don't tend to be pedantic about language unless the meaning is unclear. And if you look at my other reply, you'll see someone else misunderstood his meaning also.
Slashdot Mirror
Ugh, I hope it doesn't work like that. It would cause horrible loop problems - imagine that the sender is also using this patch. The recipient server would open a connection to the sender to verify the address. The sender would open a connection to the recipient to verify it, since at the point the verification happens it's unable to distinguish actual mail sending from this verification. So it's an endless loop between the two, consuming more and more CPU time and bandwidth for a Postfix shouting match.
If your description is accurate, this patch should never be used.
Do you have anything at all to back up that statement? Specific examples, maybe?
If this is just a denial of service attack, you're probably right. But it's often the case that when you can crash software, you can insert arbitrary code. (Buffer overflows, format string vulnerabilities...the most common causes of segfaults.) So what makes this really worrisome is not the inconvenience of restarting the browser but the fear that any website you go to can completely compromise your machine.
You might try Silencer fans instead. No fan is truly silent, but these are 20dB. IIRC, whispers are 30dB, so you might not even be able to hear it at all. Mine does not contribute tto my machine's noise in any noticeable way. I've also got a Silencer power supply. That just leaves the processor and video card fans.
To add a bit more to my reply: they definitely do this now, very easily. If the certificates were required, they probably still would occasionally, but with much more difficulty. They couldn't just send it claiming to be that person and be believed. They'd have to get it sent with the certificate, presumably by breaking into that person's computer or a computer of the ISP which issued it.
This is all assuming this hypothetical system is fully adopted, of course. At best there's like a 10-year interim period, during which unsigned emails become progressively less trusted.
I would view complete loss of anonymity as a bad thing. As my last post said, I think it will work out that people can be fairly anonymous (someone trustworthy running an aonymous remailer issues a certificate for an address, not knowing who they issued it to or just not being willing to say). So you can take on a specific anonymous identity. (You can do that now, but it's not mainstream. Not many people know about PGP.)
SPAMmers will still find ways to subvert individual's legitimate accounts. This does and will partially negate any benefits of distinctly identifying sender(s).
Agreed. But it's still an improvement. If you don't know who they are, you're doomed in the blocking them.
SPAM-filter *corporations* in the meantime benefit by adding more spam to the mix (themselves!) I find myself unable to trust any company that says it has an e-mail solution. I tend to theorize that they are at least subsidizing third party SPAMmers (indirectly or directly.)
I don't know; I tend to trust in the solution, not the person who presents it.
Certificate vendors are also suspect whenever a proposal arises that implies that all individuals need certificates. The article wasn't talking about using ssh-keygen or PGP. It was suggesting a paid CA issuing individuals certificates (or did I read too much into that?)
Yeah, I think the author was suggesting that. I wouldn't want everyone to pay Verisign either, which is why I suggested the alternative. It'd still allow the benefits of everyone having certificates without many of the problems of that scheme.
Verifying the headers at the end just doesn't work very well. Interpreting even the "Received:" headers is electronic hearsay. "Server A said that Server B said that Server C said that..." The only way I see to solve this is for each server to digitally sign what it sends to the next.
SMTP has various facilities for digital signatures: S/MIME for end content (though I think it's body text only; headers (notably subject) are sent in the clear). SSL-level certs (to verify the transport is secure). SMTP AUTH (to authenticate a user to a server that knows that user; their mail exchange). But none of them can solve even the problem of verifying Received: headers.
What's really needed is something that essentially treats these as a set of envelopes, each containing the last (and thus all the envelopes it contains). The innermost would be made by the user, the inside encrypted, and both the inside/outside (outside holding sender/recipient information) signed. The first server wraps it in its own envelope, signs it, and sends it to the next. And so on. You can skip the hearsay if you can verify signatures. When the final user opens it, the last link in the chain must be a UI that makes it really easy to understand the security implications with a "Verify" button or something.
Of course, all these certificates would require a decent PKI system. Everyone paying Verisign is just not going to work. As I mentioned in another post, I think the ideal would be to implement SecureDNS. Top-level domains issue certificates to second-level, etc. The MXs issue them to their users. So you can grab someone's public key quite easily and verify it. Plus, it's still possible to have relative anonymity, if you can talk "anonserver.com" into issuing you a certificate as "Anonymous Person 42" or whatever.
Having all the Received: headers verifiable means you can see the path a message took. It might also be beneficial to have a way of determining a reasonable path for a message to take, to avoid problems with open relays. (Though they're not as big anymore, since you can reliably tell where the message came from to begin with.) It's too late for me to think a lot about this problem, but I think using the DNS system for a domain to say what MXs may send mail to the world from it is a reasonable approach.
So it's kind of a complicated system, but I think this would let you have a lot more accountability. You could find out who sent a message or the last person who is not willing to tell you whom they issued a certificate to. If there's an excessive amount of spam from that place, block them. You just can't do that now - there's no good way of telling where a message came from.
I complete disagree with that:
First, spam is not the only important problem with SMTP. There's also identity theft. I just finished reading this article about email identity theft on CNN. When a technology problem hits CNN, you know it's not rare. If people expected email to be digitally signed, this would not have happened.
Second, individuals having certificates does not necessarily mean individuals buying certificates from Verisign. I'd imagine each MX issuing certificates to users. The MX's signature is fetched from DNS and verified against each successive higher domain until it gets to the TLD. (There is a DNS standard for this, called "SecureDNS" or something creative like that. Unfortunately, the TLDs aren't issuing certificates yet, so no one can really use it.)
Third, I believe certificates would reduce the spam problem to some extent. Every spam I get has forged headers in some way. It's hard to see where it actually came from...a mail server can just make up Received: lines behind it; you don't know if it was relaying or lieing. If servers embedded digital signatures, it'd make a big difference. Now, individual email addresses? Still yes, to a certain extent. People tend to reply to spams at the address they are sent from...which of course is bogus; nonexistant or someone else's. If they can't send a message from an account without a signature, the account has to exist and be theirs. (Or the server is theirs, or whatever. You have to think a bit about exactly who issued every certificate, but even a complex system of trust is better than none.) More accountability means it's easier to track down undesirable users of the system.
I'd also like point out (and here I'm not refuting the parent post) that I don't think the certificate thing means losing anonymity completely. There will always be someone willing to run an anonymous email server. They'll hand out certificates so you know you're talking to the same anonymous person each time. (That's good.) They may know the identity, but no one else will. If they're in a place like Seahaven, they can't be subpoenad to reveal it. If it's abused and spam is sent from there, people simply won't accept emails from that anonymous server anymore.
Cell phones use dramatically more energy than wrist watches. While on standby, power (energy use / time) should probably be comparable to a watch's[*]. But the transmitter uses much more power than a small processor and LCD. That's why cell phone battery capacity is often measured in N hours/days of standby or N minutes/hours of talk time.
I think neither method would gather enough energy to justify additional complexity in the cell phone.
[*] but it clearly isn't, as a tiny watch battery can power a watch for years, and a much larger cell phone battery can power one for a couple days at best. Anyone know what else the cell phone is doing while on standby? Does it transmit occasionally to ping the tower or something?
You're probably right. Not only that, but it'd probably be easier than present sniper rifles. They're firing from far enough away that with conventional weapons they have to lead the target, compensate for wind, etc. With a laser weapon, you'd just point where they are now. Light's a bit faster than bullets.
True, but not the strongest statement you could make. The efficiency of a chain is the efficiencies of each link multiplied together. That's much worse than just as bad as the weakest.
That's why I don't buy your original argument. You were comparing two efficiencies that just aren't comparable: that 90% has to be multiplied by something else, and that something else will also be under 100%. Just adding steps will always make the efficiency worse.
Studies into end-to-end efficiencies of EV vs ICE are available [princeton.edu].
Yes, that study is interesting. From it, I'm sold that the electrical vehicles are both cleaner and more efficient as a practical matter. But that seems to be because the larger plants are dramatically cleaner and more efficient. If they were both the maximum theoretical (with the same cycle and temperatures), which was the number you originally mentioned, the electrical one would have to be worse.
The other 32% of energy sources the study mentioned are always interesting, but there are reasons they are only 32%... maybe some day.
So basically, I'm not disagreeing with your conclusion. But that doesn't make your logic valid. The study was convincing; your original post was not.
I don't buy that argument. Motors convert electrical energy to kinetic energy. Where does the electrical energy come from? Typically a heat engine and generator. 60% * x% * 90% is less than 60%.
Looking at that list, most of your stuff deals with sendmail's virtusertable. Postfix's virtual map does the same thing. The only thing I don't know that it supports is domain mirroring, but you could accomplish that by preprocessing the virtual file a bit.
The alias file format is the same as sendmail's. (Well, not quite true; it supports two file formats; one is the same.) Everything you can do with sendmail you can do there, though you need to keep in mind that it happens as user Postfix.
The other stuff, you just need to go through the documentation more thoroughly. It'd be a waste of my time and yours to give a not-quite-as-good version of what it says. But Postfix can do those things.
Care to provide examples? I've never seen anyone actually come up with a useful thing you can do with sendmail but not postfix, for all the times people have said this.
Hell, even if you do have to patch Postfix's C source, it's probably still easier than doing whatever in sendmail's m4-preprocessed cf files. I have written a patch to Postfix, and it was not difficult.
No, they figure that anyone doing that can afford the $349 for the basic version of RedHat Enterprise Linux ES, which has a guaranteed five-year lifetime.
This page is kind of a shock to me, too[*], but they aren't abandoning enterprise people at all.
[*] - this is surprising in at least three ways:
Yes, when I get random emails claiming to be opt-out lists or that I opted in, I also don't opt out for this reason.
But this is a different situation. He opted in to a list with Audiogalaxy. A relatively reputable place, and they already knew his email address was valid because he opted in. It was a reasonable thing to do, and the spam should stop afteward. But judge apparently felt it was not practical for them to have distributed that notification to all their partners in two days, so he threw out the lawsuit. Presumably it takes them that long to distribute opt-ins also.
Really, the only problem I really see this absolutely solving is the mailing list one. I'm not willing to abandon a favorable model for everything else just so mailing lists are better. They can either cope or use a separate protocol without dragging everything else along with them.
I'm much more in favor of a new, authenticated push protocol. I think much of the spam problem could be eased by a more reliable way of knowing who sent a message.
Fucking moderators. It's not even new. Turn your brains on before giving out the "Interesting" points to stupid arguments from "eggtroll".
Agreed. There are all sorts of reasons it would be useful to log in as another user with your own credentials instead of (or in addition to) having global administrator privileges.
I even ran into an application that failed depending on your username. They'd made an audit field in an Oracle database, but didn't make it the full 30 characters long an identifier can be. So when I logged in as "LAMBS" it worked, but "MEDICINE\LAMBS" failed. That sort of thing is all but impossible to debug unless you can log in as the person experiencing the problem.
I don't like it. What if they have to reinstall, well after the contract is over and they've paid? It will spontaneously break N days later, and they'll be (legitimately) quite pissed off.
This is something I wish more systems had, but not in a hardcoded (backdoor) way. Cyrus SASL/IMAPd does it correctly: they've completely separated the concepts of authentication and authorization. So you can say "until further notice, user slamb can log in and do anything user bob can do." It serves the same purpose, but in a maintainable, open way. You can have a group of administrators that can log in as anyone, but without needing to know either everyone's password or some master password that's difficult to change if someone leaves...they can just use their own, and it can be disabled/enabled on a per-person easily.
> What exactly is that supposed to mean?
> That a government run by sociopaths who have turned China into one of the most polluted countries on earth might not be the best people in charge of drilling holes into the moon?
What, do you think they're going to make it completely inhospitable to terrestrial life? Because I've got news for you: there's no ecology there to maintain. They can't screw it up.
If you just want to be bloody-minded and argue against it, there are other choices:
Ugh! Don't do RAID0 with 8 drives! With RAID0, losing a single drive means the whole array is all but worthless. (Hard to get data off with one in eight chunks missing...) I think the longevity of a single drive is a normal distribution with a mean at its MTBF. If I remember my statistics, that means the combined MTBF is just the MTBF of a single one divided by eight. Don't divide your reliability by eight!
The RAID5 is a much better solution, since it can handle a single drive failure with no problems. The odds of two drives failing at the same time are really low. So as long as you are prompt about replacing failed drives, you can't go wrong.
Thank you. Much clearer. Hadn't realized anyone still did that, much less that there were still stores to cater to them.
No, it wasn't clear to me. I don't tend to be pedantic about language unless the meaning is unclear. And if you look at my other reply, you'll see someone else misunderstood his meaning also.