On 11/10/2003 5:59 PM, Yakov Shafranovich sent forth electrons to convey:
Just a reminder that a draft of the LMAP discussion document has been
posted and is available at:
http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap-discussion-00.txt
My feedback:
Typos: propogation, matcg and Columes aren't words.
====
No reason for including mention of ASRG is provided. Add
"A private list of LMAP type proposal writers from the ASRG hashed out
an initial version of this spec, which was then posted to the ASRG
mailing list for further discussion." ?
===
Indeed, we should remove the possibly OT paragraphs in 2.1.2. (C-R and
SMTP AUTH may well be critically flawed, but they're OT, and have found
significant use)
===
3.3 needs a correction. It falsely states that content filters can only
work if the email has already been accepted.
It should instead say "... has already been _received_." It is perfectly
acceptable, per RFC 2821, to send a <550 refusal to accept for policy
reasons> in response to the end-of-data indication, and thereby not
accept the email. SpamAssassin, for example can be configured to
operate this way.
===
Re: "Note that recipients should also publish that they use/enforce
LMAP.
(Ed.: This topic should be addressed in more detail.)"
It would be good if there were a standard computer-readable way for this
to be determined. (Some possibilities:
a welcome message
or response to the EHLO/HELO
(like "LMAP required" or "LMAP used" added to the "No UCE permitted."
when one connects to, e.g. smtp.us.messagingengine.com)
, or a DNS entry for the recipient domain.)
Perhaps we should not say that MUAs MUST NOT use/enforce LMAP at all,
which is something the current spec states implicitly - by saying that
LMAP is only about MTAs.
We should say that MUAs MUST NOT send forged* email to the alleged
sender in order to indicate that they use/enforce LMAP.
We should encourage MTAs to refuse forged* email during the SMTP
session, and if that's not possible, either accept and tag it, or
discard it.
*"forged" strictly as defined in the spec, not any kind of forgery!
===
In "'An individuals "freedom of speech", " individuals should have an
apostrophe: individual's.
They're US-centric (as is the spam problem, as
http://www.spamhaus.org/rokso/ proves) but I'd like to see the following
quotes added, though I can't really present a strong argument for it,
beyond being on topic and really good quites:
*US Federal Judge Stanley Sporkin:*
"[Spammers] have come to court not because their freedom of speech is
threatened but because their profits are; to dress up their complaints
in First Amendment garb demeans the principles for which the First
Amendment stands."
*Chief Justice Berger, U.S. Supreme Court*
"Nothing in the Constitution compels us to listen to or view any
unwanted communication, whatever its merit. We categorically reject the
argument that a vendor has a right under the Constitution or otherwise
to send unwanted material into the home of another. If this prohibition
operates to impede the flow of even valid ideas, the answer is that no
one has a right to press even 'good' ideas on an unwilling recipient.
The asserted right of a mailer, we repeat, stops at the outer boundary
of every person's domain."
===
Section 3.1, 3.2, etc. : Really good!
===
My two original cents on the record type, which it seems is settling on
TXT :
I concur that LMTP be TXT record based (unless, within the next 5
months, we can get at least ALL of the major players to commit/promise
to be on board with a new type. I think it's unlikely, and TXT is the
way to go. I think, for example MS wouldn't get on board without a lot
of public pressure - like when its recent opposition to California
anti-spam bills (SB 12/186, now law) finally vaporized under an intense
spotlight - which a technical issue like this is unlikely to create.)
Major players/products include bind (8 & 9, I assume given Vixie's
involvement), ultradns, Microsoft DNS; zoneedit, dyndns; cPanel, the top
5 DNS providing domain registrars and other major players I've missed.
Assuming we stick with TXT, we STILL NEED to get the major players who
DON'T EVEN support TXT records to get on board with doing so, and there
are several! Until we do, the claim in 5.1.1 : "LMAP currently
requires no changes to existing DNS implementations." in a sense isn't
quite true (perhaps the implementations that don't support TXT records
aren't therefore actually DNS implementations!)
===
5.1.6: Only roaming users <add this: who avoid using any of the methods
of 3.2.x> are indistinguishable from spammers
===
4.1.13:
s/existing implementation/existing implementations/
===
I hope these suggestions are appreciated.
--
Matthew
Admin note: I initially mailed this post on the 11th, from a disposable
address and it just vanished. Glitch? IMO, it would be nice if the
mailing list didn't bitbucket submissions from non-subscribers.
Apropos first steps /how to get deployment to take place/change
management: Here's my vision for how it'll happen. If the current
versions of qmail, sendmail, and postfix supported LMAP by default, LMAP
on the Internet would be inevitably on the way to success. Exchange or
Notes would likely follow, and another inevitable security bug
announcement in a few of them will cause the vast majority to upgrade.
Result: the Internet is LMAP ready for nearly any domain that wishes to
do so to roll out and have it be highly effective. At that point, it is
inevitable because it will sell itself. Anyone who gets joe-jobbed will
find out about LMAP if they look into what to do about it, and scream
loudly at admins until it protects them.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg