On Mon, 2004-04-26 at 17:09, Gordon Fecyk wrote:
I haven't sent this to the ID submissions address yet. I hoped it could get
nitpicked over first.
First off, DNS people: This is going to be a historical document. Cringe
all you want at the bizarre domain node names and abuse of TXT and wildcard
records, because I was only asked to make sure it was fit for publication in
accordance with the MARID Charter. Besides, all of that ugly stuff could be
replaced while still obtaining the same result.
I also edited section 5. Maybe the examples there will help spur some
thought about the 2821/2822 debate proceeding now. You could easily adapt
them to any other scheme.
Please nitpick this document and send nits to me:
<http://www.pan-am.ca/dmp/draft-fecyk-dmp-02.txt>
I've already covered the id-nits. I'm more interested in inconsistencies
with the flowchart and examples.
A good immediate solution. The following prevents quickly adopting
solutions for user verification procedures such as:
1-- Public key encryption techniques on from user headers creates a
scaling problem in MTA servers as it imposes intensive calculations on
a message identity with the highest variability. Such checking is best
scaled at the MUA. (Anonymous users have value.)
2-- DNS checks of from user headers depends on registered outbound MTAs
which precludes third-party relay or induces domain management that does
not scale.
3-- New mail envelopes are needed to scale for forwarding and
third-party relay as such verification would be impractical otherwise.
Over time, writing new envelopes could be introduced to facilitate
filtering on the 'from' fields. Do you see anything that would prohibit
DMP records from being used for something like SPF? The DMP approach
could be an immediate solution that provides substantial relief, but as
time allows, adding further checks based on this DNS technique also
seems possible within a much longer period.
This DMP proposal seems to get the first step right, first trust the MTA
with which a connection is allowed. Once DMP becomes mandated, a policy
could be based on a lack of prior knowledge for denying 'from' domains
not listed in their DNS records. A type of clearing house could offer
services for assessing levels of trust applied to domains. Currently
this trust with respect to domains is blind.
Getting all name server entities to add a new type of record becomes
difficult if only to have another record added that does nearly the same
function. I like the simple records and would not wish to do XML
variable lookups over http as part of translating the content of the
record. Again this raises concerns regarding overhead and scaling.
Add a notice to a message if at some point a mail DNS record
verification was not possible. This facilitates demarcating the time
when a policy is in place requiring a verification to exist prior to a
message or connection being allowed. Such a policy would seem to be
where the greatest benefits are derived.
This same notice provision should be part of a SPF proposal that should
be an extension of the DMP proposal. This would allow a simple method
to track the level of conformance. With notice percentages being
published, it becomes possible for each MTA to assess when their policy
changes to rejecting non-conforming mail. This notice could be added in
the same milter extension that checks for the outbound DNS records.
Notice conformance becomes yet another service toward getting a policy
instantiated as well.
-Doug