On 13 Jan 2004 Vivien M. <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com> wrote:
<SNIP a LOT>
We've already had a discussion on this list about this issue, and I think
the conclusion that was reached at the time was that SPF assumes:
Of the list members as they were at the time maybe, a general conclusion
maybe not.
A) Domain owners ought to be allowed to determine how their
domain is used (for email purposes)
All agree here. Some users of a domain though may disagree with the
implementation. Generally though they would take this up with the owner
of the domain.
B) All "legitimate" uses of a domain are known to the domain
owner - there is no grey area where mail is sent through
other SMTP servers, but ought to be considered legitimate
by the domain owner.
Could be. That CEO that's in another country and wants to send via
another's equipment using his domain name may be something that would
keep a lot of people from rejecting mail based on the standard. I can
see a lot of grey areas where even the owner of the domain may want to
make an exception to what they have in the DNS. Note this is the owner
of the domain we are talking about, not the system admin. ;-) The BOFH
have a lot of authority but when it starts to interfere with operations
and sales they have to back off.
C) Domain owners would not use SPF to harm their
users/customers
Not always a good assumption when we are talking about owners like AOL,
RR and SBC. They simply don't always understand the impact of some of
their decisions.
D) Users caught in the middle of SPF would be able to seek
redress (eg: an SMTP AUTH relay) from the domain owner
What about a SMTP AUTH from another SMTP host?
E) Anyone who needs their own email-sending policy different
from the domain owner's should be using their own domain
Correct, if allowed by the people providing the connection.
F) Most domain hosting (and by domain hosting, I mean DNS
hosting, web hosting shops, etc) providers will give
domain customers the ability to set their own SPF policy
(as opposed to having the hosting provider set up a
boilerplate SPF record requiring the use of the hosting
provider's relay or something)
Generally correct, some are less than tightly wrapped and may or may not
provide the correct tools.
If you assume those three things, then SPF makes perfect sense as an
antiforgery mechanism. If, however, you believe that that some of the latter
four are inaccurate, then obviously you're going to have a lot more of a
problem with SPF.
Anti-forgery correct.
That said, read the archives: this horse has been beaten, killed, and buried
at least a couple of times before.
But the horse is going to keep climbing back out since there are a lot of
people that are going to be affected by how this is going to be
implemented. We are not talking about anti-forgery now, we are talking
about anti-spam. There appears to be some assumption that mail from a
"forged" source is spam.
I see tagging mail as a forgery with it's received from a source not
specified by the domain owner. I cannot see rejecting mail based on this
standard alone.
Vivien
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
Thomas R. Stephenson, CPL Phone: (408) 742-3308
Lockheed Martin Technical Operations
MILSTAR Logistics Engineering O/M5-41 B/158
P.O. Box 61687 Sunnyvale, CA 94088-1687
Member Pegasus Mail Support Team
Thought for the day:
Elvis stamp = 29>, donut = 29>. Coincidence? I think not!
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡