At 06:39 PM 5/11/2005 -0400, Terry wrote:
David MacQuigg wrote:
At 01:06 PM 5/11/2005 -0700, William Leibzon wrote:
On Wed, 11 May 2005, David MacQuigg wrote:
I'm not assuming the problem is not inherent, or that somehow you can
check the RFC2822 name against an SPF1 record.
You can check any name you like against SPF1 record. Its rather the
question of results of such a check and if spf1 record was setup on
purpose to accomodate this check.
I agree. What I like about Wayne's new wording is that keeps a firm NOT
RECOMMENDED, yet allows other identities to be used under the right conditions.
Without explicit approval of the record owner, checking other
identities against SPF version 1 records is NOT RECOMMENDED
This approval could be in the form of a clear, unambiguous declaration of
the sender's identity, with no conflicting requirements. OK:
"Hello, this is ebay.com, sending from <IP>. You can check that any way
you want."
No
It should be this is ebay.com connecting from <IP>
---> and then a DNS lookup on ebay.com reveals that the TXT record says
its SPF record can be used against other scopes.
It should never *ever* be the connecting MTA that says what scopes to use,
the whole point is that you cannot trust the connecting MTA (it could very
well be a lying forging spam relaying server or zombie)
You are right, the connecting MTA should not decide (by itself) what scopes
to use. The decision is made (indirectly) by the receiving MTA and the
purported Identity. There must be a method they both support. Maybe I
should have said "use any method(s) you want". The subsequent DNS hunt
will show whether that method is supported. The authentication header will
show what method was finally used.
When I focus on a small piece of a problem, it is hard to convey that what
I have in mind actually does fit in with a larger plan. I have thought
about the subsequent steps. I don't want to start a long discussion off
the topic of SPF, but you are welcome to see the whole plan, currently
under construction, at http://purl.net/net/macquigg/email Maybe I should
just say, trust me ... Or maybe, please read my words a little more
carefully before you react. We need to keep the diversions on this list to
a minimum.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *