On Wed, 7 May 2003 23:04:02 -0700 (PDT)
Michael Rubel <asrg(_at_)mikerubel(_dot_)org> wrote:
But without RMX, there was nothing I could do about it.
Here we part. I don't consider RMX to be a suitable address to the
problem.
Just to be clear, I'm assuming you mean by this that you agree RMX
would fix the forgery problem at a technical level, but are not
satisfied with RMX because it gives domain administrators per-message
control over their outgoing mail, rather than per-sender control. Is
that correct?
Almost. RMX would not fix or prevent the forgery problem, but it would
curtail some of the more obvious abuses, but achieves that end by a
large reduction in the capabilities and freedoms of the current
arrangement. Its a bandaide, not a fix (bandaides are Okay, but should
be recognised as such).
My gripes with RMX are various and not limited to the recent authority
domain discussion; ranging from deployment costs to percentage
deployment threshold requirements, social implications, breaking of
extant useful architectures, and a relatively poor value in the level of
authentication it provides (due to the reliance on side-effects of the
record).
If this is your opinion, I respect it, but I disagree; I don't feel
that making it technologically impossible for a domain to apply
message-level controls to its outgoing mail is a desirable feature.
This is because if we are to feel justified in holding domain admins
responsible for spam from their domains, then we owe them the
reasonable opportunity to prevent it.
Oh come now! We don't hold domain operators responsible for spam
claiming to be from their domain, and never have. That's a ridiculous
red herring. We hold network and host operators responsible for spam.
The problem has never been identifying domain operators, but correctly
identifying networks and hosts and then the people behind them. The
actually fundamental value that RMX adds in this space is based on the
fact that it requires outbound mail to be routed thru domain-named IP
addresses, and ONLY routed thru those addresses so that they can be used
in an effort to provide a better back trail to the network and host
operators responsible for originating the spam. Without that
centralised routing RMX sunders. The use of the domain is just a
foreign key in the identification transaction, nothing else -- its a key
that you use to map a received mail back to an IP address which you can
lookup in WHOIS and hit or react appropriately with at least some minor
semblance of correctness.
RMX is a targeting tool, and one with rather poor guarantees and audit
trails. Its a particularly ugly targeting protocol as the natural
inclination on the receiving end is to ignore the identified targets and
to instead simply ghetto-ise those without targeting identifiers, while
the sending end is naturally tempted to machine wash all mail sent.
If you send me a paragraph or two explaining why you feel that
message-level controls ought to be impossible...
Arrrgh. That is not and has never been my contention.
Here's the condensed version:
The sending and receipt of a mail is a contract between the sender and
the recipient. The definition and terms of that contract are
subjective to those involved. The use of external symbols and
referents in the contract, like domain names, is relevant to those
involved in the contract, not the referents.
Mail, like all human communication, is an autonomous peer-to-peer thing.
Domain names and the rest of that are convenience trappings and
abstractions, no more.
Furthermore, if you can think of a reasonable alternative and provide
a link, I'll include it.
<nod> I'm working on it. Its a rough space -- you've got three nodes
among DNS, the originating node, and emitted message, and establishing
validation creds for a message (not an SMTP transaction) without
requiring a shared secret between DNS and the emitting node is rough.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(_at_)kanga(_dot_)nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg