And you point out what SPF tries to downplay: The ultimate purpose of ?all is to be treated as spam. Therefore, any "solution" that suggests use of ?all is disingenuous.
And you can't just say, "If you can't use SMTP AUTH, use webmail", because once again you're assuming that the individual wishing to use email has some magical sway over the services offered by those running the MTA from which they receive email.
A customer can't just call up their ISP or their company and say, "Hey! Since you won't offer this service that I've asked for, you need to offer this other service that I've asked for! After all, the SPF supporters claim it's trivial for you to do it, and they can't understand why you can't just flip a switch and make it happen!"
Honestly, the lip service the SPF crowd pays in the form of "solutions" to problems SPF presents are ballsy. They assume that everyone will just reconfigure their mail services to meet the needs of SPF. They assume that all mail servers will offer SMTP AUTH, MSA, webmail, SSL, and so on. They assume all ISPs will happily leave ports 25, 587, and so on unblocked and un-transparent-proxied. They assume all MUAs will magically sprout the ability to use MSA, SSL, SMTP AUTH, and so forth (apparently, they haven't looked at the burgeoning use case of email from cellphones, and the extremely limited feature set on those MUAs, and the extremely long (year-plus) development/deployment cycle for updating those MUAs.)
When they're not assuming this, they're assuming that everyone will be just peachy using 5 different email addresses depending on where they're trying to send email from, rather than wanting to use a single address regardless of location. Like it or not, "Reply-To:" is not seen by many humans, and the identity associated in the minds of recipients with the sender is that in the RFC2822 From: header. Users don't want to change email addresses based on physical location. Schemes like SPF would force this when niceties like SMTP AUTH, MSA, a fully-featured MUA, an MUA the user can reconfigure, VPN, unfiltered ports, and webmail aren't available.
The SPF crowd needs to understand something: There are serious technical and social problems with SPF that will limit adoption, and the handwaving they're doing towards the problems isn't helpful, it's aggravating and unrealistic.
Pointing out problems with SPF and working towards a solution that doesn't have those problems and may not be immediately deployable is not tantamount to "being in favor of spam".
you miss the point. Forwarding is requested by the email recipient, but it's handled by the IT staff.
And the email recipient and the ISP to which the email recipient belong are two entirely separate things. The person requesting forwarding has no control over how the MTA reciving forwarded emails handles those emails, nor does the person requesting forwarding have the ability to bring that forwarding to the attention of the ISP.
Sure, the person could send an email saying, "hey, so-and-so will be forwarding email to me!", but my point in mentioning AOL is this:
for any large ISP, managing the notification and inclusion of hundreds of thousands if not millions of individual forwards is a logistical nightmare, and it's the height of hubris to suggest that the solution is just "notify the recipient MTA of the forwards".
The easiest solution is to simply leave the default for your SPF record as "?all"
This would effectively be saying, "I'm probably spam; please filter me."
Why on Ghu's green Earth do all the SPF supporters assume that SMTP AUTH and similar approaches are available in every MUA, and from every location from which one might send email? Why do they insist on assuming that email users have control over the configuration of the MXes for the domains they wish to stick in the RHS of the RFC2822 From: header?
There are plenty of situations (most common: purchased domain name with full hosting) in which the mail sender has a legitimate right to use the domain name in the From: header, but has no control over, and no say in how the MXes for that domain are configured, or what is and isn't allowed in terms of connectivity.
You should not be using the hotel's SMTP server, or any other SMTP server except the one for your domain.
There are such things as MUAs that don't relay outgoing mail through an SMTP server -- they connect directly to the destination MTA.
SPF wants to eliminate this form of email. Change your From: header every now and again? You'll have to reconfigure your MUA as well. Or reconfigure your local MTA to relay mail through an "authorized" MX for the domain you're using. (Case in point: you'll need to change the server used by mutt based on the contents of your outgoing RFC2822 From: header. Or any other mail client you use. But everyone uses those purty GUI point-n-drool MUAs these days, don't they? That shouldn't be a problem! Feh.)
Now, it's not enough that you own your own domain. You'll also need control over the TXT RRs associated with that domain, and the MXes for that domain, to ensure your mail gets through.
The SPF folks tend not to care about people who're travelling. They insist it's not a widespread problem, and they insist that everyone should be using SMTP AUTH.
Of course, they ignore situations where people are using cellphones to send email, and other situations in which the person is behind a transparent proxy over which they have no control, which molests the RFC2821 headers. Or situations in which the person sending email is using an MUA over which they have no control. They expect everyone to reconfigure their MUA every time they want to change the RFC2822 From: header. That'll go over well with the average Joe.
If you bring the issue up, they'll paint you as a whiner and a troublemaker, stick their fingers in their ears and pretend they can't hear you.
Why? Because SPF is good, and if you don't support it, you must be pro-spam. Because if you're not with them, you obviously support the terrori^Wspammers.
...why there were blue-shirted Google employees standing at the parking lot entrance this morning, greeting and occasionally stopping each incoming car at their new Mountain View campus (not the HQ building, but the ones recently vacated by SGI).
Normally, this lot entrance is completely obstacle-free.
You see, for years now the software, music, and movie industry have implicitly asserted that each copy of an item pirated was a lost sale.
With this major bust, the supply of new pirated software titles should drop precipitously.
Once and for all, we can watch the sales figures and determine whether or not there's any relation between piracy and sales.
...and once it's clear that the dearth of available pirated software has no positive impact whatsoever on software sales, we can tell these groups to get well and truly stuffed.
How long until some worm is written that uses the automatic notice/account-disabling feature to systematically cause the disabling of every account in existence?
a) SPF is being considered by the same working group. Rather, the means of authenticating senders via DNS that both SPF and Caller-ID propose are being considered by the same working group. Caller-ID, however, is more focused on RFC2822 headers, whereas the working group is learning towards RFC2821 headers in its initial product.
b) "Caller-ID" is copyrighted, and will almost certainly not be used as a final name.
c) True. However, the working group will not be choosing one approach from whole cloth. Rather, it will be producing a DNS-based means of sender authentication, which other working groups will then build upon to produce a full-fledged mechanism, which may or may not be an existing mechanism, a combination of several, or something new.
It may be helpful to explain to people the exorbitant tax rate you face when asking for donations, then. I'm much more sympathetic to the request knowing that 2/3rds disappears into the government ether.
USD$5500/month? That's more than my net take home, and that's with a $415k mortgage to feed!
It may be where his budget balances, but if he expects to live off the kindness of strangers, he needs to adjust his budget substantially.
He's got some enormous cojones asking people to give him what amounts to $66,000 net/year salary (it'd be over USD$100,000 gross/year were he salaried).
the only email that'll make it past everyone's spamfilters would be that from MXes in the.mail TLD....and those of us who can't shell out $2k/year just to have our private domain in.mail are just screwed.
Brilliant idea. While we're at it, why don't we just let ICANN authoritatively say who can and can't send mail, and be done with it? It's not like their board is captured or anything.
This is why having a firewall running on the machine(s) it's supposed to protect is idiotic.
When will the Windows world (and, to a lesser extent, the *nix world) wake up and realize that putting all services on a single box is just asking for trouble?
A firewall should be a dedicated, hardened host that is easily rebuilt if compromised. A firewall should not be the only layer of security.
So you put the black box between $ANTENNA and $DEVICE instead. ATSC is unencrypted and fully documented.
Okay, so that takes care of 6 or so local channels.
How do you intend to do this for $CABLE_BOX, $SATELLITE_RECEIVER, $DVD_PLAYER, $PVR, and any other source, which will connect via HDMA?
If you take note the devices hitting the market now with HDMA connections, they come in two flavors:
Devices with both HDMA and component connections, that limit the maximum quality output on the analog output, and
Devices without analog output, only HDMA.
Further, those with both HDMA and analog outputs have the capability to have the analog outs remotely disabled (in cases where there is an upstream signal, such as cable boxes and satellite receivers).
It's all well and good to keep saying, "bring it on, we'll hack it!" but at some point, people need to take a stand and make companies stop criminalizing our daily behavior.
In a free society, the correct answer to unjust laws is not just to break them; it's to willfully disobey while working from within to repeal said laws. I see a whole lot of the former here, and very little of the latter.
Slashdot Mirror
This would be the same qmail that has an accept-then-reject approach to email?
The same qmail whose author selectively implements only those bits of the RFCs with which he agrees?
No, thanks.
Are you saying that the receiving site that checks SPF must keep track of every MTA that forwards mail to one of their users?
Yes, that's exactly what they're saying. And when people balk, they act as though it's no big deal.
And you point out what SPF tries to downplay: The ultimate purpose of ?all is to be treated as spam. Therefore, any "solution" that suggests use of ?all is disingenuous.
And you can't just say, "If you can't use SMTP AUTH, use webmail", because once again you're assuming that the individual wishing to use email has some magical sway over the services offered by those running the MTA from which they receive email.
A customer can't just call up their ISP or their company and say, "Hey! Since you won't offer this service that I've asked for, you need to offer this other service that I've asked for! After all, the SPF supporters claim it's trivial for you to do it, and they can't understand why you can't just flip a switch and make it happen!"
Honestly, the lip service the SPF crowd pays in the form of "solutions" to problems SPF presents are ballsy. They assume that everyone will just reconfigure their mail services to meet the needs of SPF. They assume that all mail servers will offer SMTP AUTH, MSA, webmail, SSL, and so on. They assume all ISPs will happily leave ports 25, 587, and so on unblocked and un-transparent-proxied. They assume all MUAs will magically sprout the ability to use MSA, SSL, SMTP AUTH, and so forth (apparently, they haven't looked at the burgeoning use case of email from cellphones, and the extremely limited feature set on those MUAs, and the extremely long (year-plus) development/deployment cycle for updating those MUAs.)
When they're not assuming this, they're assuming that everyone will be just peachy using 5 different email addresses depending on where they're trying to send email from, rather than wanting to use a single address regardless of location. Like it or not, "Reply-To:" is not seen by many humans, and the identity associated in the minds of recipients with the sender is that in the RFC2822 From: header. Users don't want to change email addresses based on physical location. Schemes like SPF would force this when niceties like SMTP AUTH, MSA, a fully-featured MUA, an MUA the user can reconfigure, VPN, unfiltered ports, and webmail aren't available.
The SPF crowd needs to understand something: There are serious technical and social problems with SPF that will limit adoption, and the handwaving they're doing towards the problems isn't helpful, it's aggravating and unrealistic.
Pointing out problems with SPF and working towards a solution that doesn't have those problems and may not be immediately deployable is not tantamount to "being in favor of spam".
you miss the point. Forwarding is requested by the email recipient, but it's handled by the IT staff.
And the email recipient and the ISP to which the email recipient belong are two entirely separate things. The person requesting forwarding has no control over how the MTA reciving forwarded emails handles those emails, nor does the person requesting forwarding have the ability to bring that forwarding to the attention of the ISP.
Sure, the person could send an email saying, "hey, so-and-so will be forwarding email to me!", but my point in mentioning AOL is this:
for any large ISP, managing the notification and inclusion of hundreds of thousands if not millions of individual forwards is a logistical nightmare, and it's the height of hubris to suggest that the solution is just "notify the recipient MTA of the forwards".
Only broken SPF implementations break forwarding. It is incorrect to block mail from a known forwarder.
/etc/mail/aliases to AOL addresses.
At work, we forward certain employees' emails via
How, exactly, do you propose we go about informing AOL of this?
How, exactly, do you propose AOL manage a situation where the entire world has to inform them of every instance of forwarding?
The easiest solution is to simply leave the default for your SPF record as "?all"
This would effectively be saying, "I'm probably spam; please filter me."
Why on Ghu's green Earth do all the SPF supporters assume that SMTP AUTH and similar approaches are available in every MUA, and from every location from which one might send email? Why do they insist on assuming that email users have control over the configuration of the MXes for the domains they wish to stick in the RHS of the RFC2822 From: header?
There are plenty of situations (most common: purchased domain name with full hosting) in which the mail sender has a legitimate right to use the domain name in the From: header, but has no control over, and no say in how the MXes for that domain are configured, or what is and isn't allowed in terms of connectivity.
You should not be using the hotel's SMTP server, or any other SMTP server except the one for your domain.
There are such things as MUAs that don't relay outgoing mail through an SMTP server -- they connect directly to the destination MTA.
SPF wants to eliminate this form of email. Change your From: header every now and again? You'll have to reconfigure your MUA as well. Or reconfigure your local MTA to relay mail through an "authorized" MX for the domain you're using. (Case in point: you'll need to change the server used by mutt based on the contents of your outgoing RFC2822 From: header. Or any other mail client you use. But everyone uses those purty GUI point-n-drool MUAs these days, don't they? That shouldn't be a problem! Feh.)
Now, it's not enough that you own your own domain. You'll also need control over the TXT RRs associated with that domain, and the MXes for that domain, to ensure your mail gets through.
Whee.
The SPF folks tend not to care about people who're travelling. They insist it's not a widespread problem, and they insist that everyone should be using SMTP AUTH.
Of course, they ignore situations where people are using cellphones to send email, and other situations in which the person is behind a transparent proxy over which they have no control, which molests the RFC2821 headers. Or situations in which the person sending email is using an MUA over which they have no control. They expect everyone to reconfigure their MUA every time they want to change the RFC2822 From: header. That'll go over well with the average Joe.
If you bring the issue up, they'll paint you as a whiner and a troublemaker, stick their fingers in their ears and pretend they can't hear you.
Why? Because SPF is good, and if you don't support it, you must be pro-spam. Because if you're not with them, you obviously support the terrori^Wspammers.
As long as SPF breaks forwarding (and as long as SPF supporters behave as though this is no big deal), it'll fail.
/etc/aliases! (postmaster and abuse accounts, anyone?)
SRS is nothing but re-hashed bang-pathing, and the SRS folks don't address any of the problems inherent in bang-pathing.
Show me a Unix system that doesn't use
...why there were blue-shirted Google employees standing at the parking lot entrance this morning, greeting and occasionally stopping each incoming car at their new Mountain View campus (not the HQ building, but the ones recently vacated by SGI).
Normally, this lot entrance is completely obstacle-free.
And you must be a dropout. ;)
:(
Yeah. I left University before defending my Ph.D dissertation. I only have two degrees.
You see, for years now the software, music, and movie industry have implicitly asserted that each copy of an item pirated was a lost sale.
...and once it's clear that the dearth of available pirated software has no positive impact whatsoever on software sales, we can tell these groups to get well and truly stuffed.
With this major bust, the supply of new pirated software titles should drop precipitously.
Once and for all, we can watch the sales figures and determine whether or not there's any relation between piracy and sales.
I was hoping that the high level of skill required would account for something
A college degree does not confer skill. Skill must be demonstrated before it can be rewarded.
How long until some worm is written that uses the automatic notice/account-disabling feature to systematically cause the disabling of every account in existence?
Not long, I think.
a) SPF is being considered by the same working group. Rather, the means of authenticating senders via DNS that both SPF and Caller-ID propose are being considered by the same working group. Caller-ID, however, is more focused on RFC2822 headers, whereas the working group is learning towards RFC2821 headers in its initial product.
b) "Caller-ID" is copyrighted, and will almost certainly not be used as a final name.
c) True. However, the working group will not be choosing one approach from whole cloth. Rather, it will be producing a DNS-based means of sender authentication, which other working groups will then build upon to produce a full-fledged mechanism, which may or may not be an existing mechanism, a combination of several, or something new.
Trust me...1400 sq. ft. is not "too much house". And it's a townhome. Life in Silicon Valley is very expensive, housing-wise.
It may be helpful to explain to people the exorbitant tax rate you face when asking for donations, then. I'm much more sympathetic to the request knowing that 2/3rds disappears into the government ether.
USD$5500/month? That's more than my net take home, and that's with a $415k mortgage to feed!
It may be where his budget balances, but if he expects to live off the kindness of strangers, he needs to adjust his budget substantially.
He's got some enormous cojones asking people to give him what amounts to $66,000 net/year salary (it'd be over USD$100,000 gross/year were he salaried).
A short book I wrote on the subject is available from USENIX/SAGE.
the only email that'll make it past everyone's spamfilters would be that from MXes in the .mail TLD. ...and those of us who can't shell out $2k/year just to have our private domain in .mail are just screwed.
Brilliant idea. While we're at it, why don't we just let ICANN authoritatively say who can and can't send mail, and be done with it? It's not like their board is captured or anything.
They have. Netcraft isn't instantaneous, and this has only been known for a few days.
This is why having a firewall running on the machine(s) it's supposed to protect is idiotic.
When will the Windows world (and, to a lesser extent, the *nix world) wake up and realize that putting all services on a single box is just asking for trouble?
A firewall should be a dedicated, hardened host that is easily rebuilt if compromised. A firewall should not be the only layer of security.
I agree.
So much so that I've been working on just such a system.
That's because there's an almost-identical flag already in HDCP. No need for duplication of effort.
Okay, so that takes care of 6 or so local channels. How do you intend to do this for $CABLE_BOX, $SATELLITE_RECEIVER, $DVD_PLAYER, $PVR, and any other source, which will connect via HDMA?
If you take note the devices hitting the market now with HDMA connections, they come in two flavors:
Further, those with both HDMA and analog outputs have the capability to have the analog outs remotely disabled (in cases where there is an upstream signal, such as cable boxes and satellite receivers).
It's all well and good to keep saying, "bring it on, we'll hack it!" but at some point, people need to take a stand and make companies stop criminalizing our daily behavior.
In a free society, the correct answer to unjust laws is not just to break them; it's to willfully disobey while working from within to repeal said laws. I see a whole lot of the former here, and very little of the latter.