If that kind of thing were covered by the commerce clause, then why is it described elsewhere, in such detail that it specifically excludes what you're talking about?
The RFC forbids rejecting the message due to the domain of the EHLO string not matching the IP address of the sender.
It doesn't say anything about rejecting based on EHLOs that are missing, badly formed, refer to nonexistent addresses, etc.
So I certainly may and will use the EHLO string to block senders, as long as I don't reject mail for the reason that the connecting IP doesn't like up with the EHLO (which would be stupid for many reasons).
RFC 821 has specific requirements about the return path, then RFC 1123 says those are void, and so the conclusion is that RFC 1123 says they're still intact?
I often send email from my servers on behalf of third parties, with the return path being the email address of the third party, because that's where I want the bounces to go. Is this illegal according to RFCs currently in effect?
But due to RFC 1123, if you place another mail server's hostname in the "MAIL FROM" line, you are committing forgery, regardless of any ad-hoc justification you may come up with for "permitting" it.
I don't see that in RFC 1123. Can you be more specific? I could easily have missed it.
The currently proposed FairTax taxes necessities, as defined based on the poverty line, at 0% via a rebate. It is the most poor-friendly tax ever. Bleeding hearts should be eating it up.
After necessities, why should the poor pay a lower percentage of tax on the items they buy than anyone else?
Well, that's nice, but there are many other web servers and proxy servers in Debian which are still vulnerable. And from what I can tell, there are no plans to fix the root vulnerability in stable. What are we supposed to do?
It's the read latency, not MB/s that's most important for desktop usage or for most databases. Everybody quotes the numbers that they're used to quoting, but the game is different with SSDs.
So why are people's emails going into a blackhole, rather than them getting a bounce from their server?
Or maybe I misread your original sentence about people contacting you out-of-band; I interpreted that to mean they had no clue why you weren't answering, but it could easily be as a result of an undeliverable notification. My bad.
If that kind of thing were covered by the commerce clause, then why is it described elsewhere, in such detail that it specifically excludes what you're talking about?
That would require a Constitutional amendment.
Of course, an awful lot of stuff that should, doesn't, so maybe it wouldn't.
If AMD and Nvidia can truly make competitive products, then having more of a non-Intel option makes that option seem much more mainstream.
The RFC forbids rejecting the message due to the domain of the EHLO string not matching the IP address of the sender.
It doesn't say anything about rejecting based on EHLOs that are missing, badly formed, refer to nonexistent addresses, etc.
So I certainly may and will use the EHLO string to block senders, as long as I don't reject mail for the reason that the connecting IP doesn't like up with the EHLO (which would be stupid for many reasons).
There are a lot of assertions here, but no quotes or references to specific parts of RFCs.
The RFC never said anything about adding some other server's address to a MAIL FROM line
A server doesn't go in there, an email address does. The address of the sender.
That is: by listing an address in mail from, you PROMISE you can immediately return mail to the host you received it from
Who says? Is "PROMISE" defined like "SHOULD", "MAY", "SHOULD NOT", etc?
Please bear with me, I'm confused.
RFC 821 has specific requirements about the return path, then RFC 1123 says those are void, and so the conclusion is that RFC 1123 says they're still intact?
I often send email from my servers on behalf of third parties, with the return path being the email address of the third party, because that's where I want the bounces to go. Is this illegal according to RFCs currently in effect?
But due to RFC 1123, if you place another mail server's hostname in the "MAIL FROM" line, you are committing forgery, regardless of any ad-hoc justification you may come up with for "permitting" it.
I don't see that in RFC 1123. Can you be more specific? I could easily have missed it.
SPF is harmful.
This is a US site; it isn't spelled "spelt" it's spelled "spelled"!
There's no "insensitived". It's "incited".
Same thing happens to me every time I do a Wolfram Alpha search.
The currently proposed FairTax taxes necessities, as defined based on the poverty line, at 0% via a rebate. It is the most poor-friendly tax ever. Bleeding hearts should be eating it up.
After necessities, why should the poor pay a lower percentage of tax on the items they buy than anyone else?
Somebody's fired.
What about the Pre's browser? It'd be interesting to see how it differed from Safari.
It's a good thing you didn't use rant mode. From the original Ask Slashdot question:
"If you run them at their original resolution, they're tiny"
So that option has been considered and rejected.
The problem doesn't appear to be the size of the windows, but the size of the pixels. Virtualization wouldn't help here.
I'd like a cheese pizza and a large soda, please.
Well, that's nice, but there are many other web servers and proxy servers in Debian which are still vulnerable. And from what I can tell, there are no plans to fix the root vulnerability in stable. What are we supposed to do?
You just need to load the kernel from some other medium. An old hard drive, a USB stick, an old flash card or something.
Unless you're running a truly backwards OS like Windows. Then, yeah, you have to put a lot of stuff on your boot drive.
It's the read latency, not MB/s that's most important for desktop usage or for most databases. Everybody quotes the numbers that they're used to quoting, but the game is different with SSDs.
You're looking for Yakuake. It's just like Quake: hit the tilde and a command console drops down from the top.
Actually it was soccer.
So why are people's emails going into a blackhole, rather than them getting a bounce from their server?
Or maybe I misread your original sentence about people contacting you out-of-band; I interpreted that to mean they had no clue why you weren't answering, but it could easily be as a result of an undeliverable notification. My bad.
It's not a problem for Web sites, except for their users that run crappy software (ie Flash).
They're desperate to show that they're doing something. Make it so they have to do something to maintain the status quo and everybody's happy.