I think the point was that many people will be just confused by
"example.com is not authorized to use address [1.2.3.4]"
They may try to contact the receiver and say
"did you get my email, I think you have a problem"
The people on this list would understand, but not my mom!
I think my mom would give up and just accept that she can't send emails to
some people.
Guy
________________________________________
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of David
MacQuigg
Sent: Thursday, February 24, 2005 5:14 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Handling of -all
At 01:39 PM 2/24/2005 -0800, you wrote:
Quoting David MacQuigg <dmq(_at_)gain(_dot_)com>:
What people do you have in mind? I am thinking about people who operate
public mail servers. If they don't understand a simple reject message
("Sorry, wrong number.), they shouldn't be operating a public mail
server. If they can't fix the problem themselves, and they can't afford
to
pay someone to fix it, then they can't be serious about wanting to operate
a public mail server. Private mail servers can go do what they want, but
operating a public mail server should be a public trust. Anyone who
abuses
that trust does not deserve out sympathy.
"People who operate public mail servers" -- especially the very large ones
-- do
not sit between their users and their users' correspondents' servers,
explaining and handling bounces and rejections for them. Instead, the
confusing responses are most often delivered directly to non-technical end
users.
I guess I will need a specific example. Let's say I send a message to
someone at pobox.com, and it comes back "gain.com ( my ISP ) is not
authorized to use address [217.183.69.117]". I'm going to call gain.com,
and they will be getting a lot of calls from subscribers like me. I suppose
gain.com could try to blame it on pobox.com, but that excuse is going to get
pretty lame after 100 complaints.
Give me a scenario where the wrong people get blamed.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq(_at_)gain(_dot_)com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
________________________________________
Sender Policy Framework: http://spf.pobox.com/ Archives at
http://archives.listbox.com/spf-discuss/current/ Read the whitepaper!
http://spf.pobox.com/whitepaper.pdf To unsubscribe, change your address, or
temporarily deactivate your subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com