On Wed, 2004-04-28 at 01:13, Matthew Elvey wrote:
On 4/27/04 7:36 AM, Meng Weng Wong sent forth electrons to convey:
On Tue, Apr 27, 2004 at 06:51:23AM -0700, Hallam-Baker, Phillip wrote:
|
| Accreditation is out of scope here, but MARID is a component of a
| spam solution not a complete solution in itself.
|
| Today MARID + Spam filter = improved spam situation
| Future MARID + Accreditation = The end of spam
|
On that note, I would like to announce that the SPF draft has added an
accreditation modifier. It should be sufficient for linking to
accreditation services. The deliverability industry has responded well
to this proposed addition. Comments and criticism welcome.
I'm disappointed that the following remains un-addressed in the new
spf-draft-200404.
What's up with that?
(I've emailed you privately, repeatedly, and even called your co-author
about this; no response.)
draft-mengwong-spf-01.txt needs appropriate boilerplate, specifically
"This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026."
and NOT the boilerplate it currently has:
"This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 _except that the right to produce derivative_
_works is not granted._"!
It is quite plainly Standards Track, not an experimental RFC hopeful.
I've tried repeatedly to resolve this privately, but not made any headway.
Apologies for the lack of technical content to this post, but it's not OT-
it's relevant because it'll impact feasibility of reliance on SPF by MARID.
Technical post to follow... why I'm now liking Crocker's proposal++.
--
Matthew
Appendices:
On 4/12/04 11:24 PM, I sent forth electrons to convey:
Hello?
I haven't heard back; re-sending before I conclude I'm being ignored and
contact someone else.
-Matthew
There are two basic issues to be resolved. One key concept is the use
of DNS records to reveal outbound SMTP traffic ownership. This alone
should have a major impact with respect to the amount of spoofed mail
entering the system as it acts as a type of SMTP MTA validation. A
secondary issue is how this information can be extended over time to
include 'from' validations.
There should be a draft using an agnostic approach as to the syntax for
these outbound records that may bridge domains. The syntax should be
relatively extensible but simple.
The secondary issues such as how this can be extended over time such as
how envelopes are to be rewritten, will happen much latter. The time it
will take to resolve and deploy these secondary use issues beyond SMTP
MTA validation should not delay being able to reject connections
spoofing the helo domain. Even getting this practice in place to allow
SMTP MTA validation will take time but will provide substantial relief.
Establish a group responsible for developing a DNS draft independent of
these secondary uses. The principle objective should be MTA validation,
and the secondary objective should be 'from' validation. With the
concept of specifying an accreditation service, the need for 'from'
validation may become moot. The 'from' validation best scales at the
MUA where it can become iron clad while still scaling.
-Doug
On Sun, 21 Mar 2004 14:48:34 -0800, I
said:
On 3/17/2004 10:26 AM, <I-D editor> sent forth electrons to convey:
Could you please contact the author on this regards.
I already did attempt this - note the
"I received no reply to this: "
and
"I have attempted to resolve these issues directly, unsuccessfully."
in my previous email. That's why I'm contacting you.
1)The memo seems not to be in compliance with RFC2026! The boilerplate
"This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 _except that the right to produce derivative_
_works is not granted._"
Is not acceptable because the draft IS largely a derivative of other
people's IETF I-Ds published with the regular boilerplate, and this
boilerplate is only acceptable for a draft that is a republishing of
NON-IETF work AND is NOT intended for Standards Track publication,
according to <http://www.ietf.org/ietf/1id-guidelines.txt>. The spf
website makes it fairly clear that the draft IS intended for Standards
Track publication.
2)I was not credited for some small contributions I made that were
incorporated. (BFD; I care more about 1)), but my interpretation of
the rules is that at a minimum, contributions that makes it into the
spec should be acknowledged.
I have attempted to resolve these issues directly with the authors,
but they have been unresponsive. I would try calling, but they provide
no phone #s in the draft.
I found a phone number for Mark - (650) 964-xxx and called him; and
discussed these two issues. He said he didn't know how Meng would be
handling them, but that he was the one dealing with them, not him.
-Matthew.