J.C.,
JCL> My gripes with RMX
[ ... (include) ... ]
JCL> ...a relatively poor value in the level of authentication it provides
JCL> (due to the reliance on side-effects of the record).
I disagree, but you aren't giving me something specific to respond to
here.
MR> If this is your opinion, I respect it, but I disagree; I don't feel
MR> that making it technologically impossible for a domain to apply
MR> message-level controls to its outgoing mail is a desirable feature.
MR> This is because if we are to feel justified in holding domain admins
MR> responsible for spam from their domains, then we owe them the
MR> reasonable opportunity to prevent it.
JCL> Oh come now! We don't hold domain operators responsible for spam
JCL> claiming to be from their domain, and never have. That's a ridiculous
JCL> red herring.
Not at all. Domain admins suffer by being blacklisted when their domain
names are misused. Some recipients dump any mail claiming to originate
from hotmail.com, regardless of its true source, for example. It is in
this sense that domain owners are held responsible. For the record I
don't agree with content filtering, but that choice belongs with the
domain owner, not me.
Content filtering is not the only option, either.
By allowing domain owners to impose outbound SMTP rate limiting, RMX
gives them the power to prevent their names from being used to deliver
bulk spam even when their clients' poorly-secured desktop machines are
compromised.
JCL> The actually fundamental value that RMX adds in this space is based on
JCL> the fact that it requires outbound mail to be routed thru domain-named
JCL> IP addresses, and ONLY routed thru those addresses so that they can be
JCL> used in an effort to provide a better back trail to the network and
JCL> host operators responsible for originating the spam.
I'm not interested in chasing down the spammer; I just want to minimize
the probability that his messages successfully reach me, particularly if
they're deliberately misleading. RMX helps there.
MR> RMX is a targeting tool, and one with rather poor guarantees and audit
MR> trails.
RMX isn't supposed to produce auditing trails, except in the case of
legitimate (non-forged) mail. I believe its true design features stand on
their own.
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.
You have a point about sending domains being tempted to machine-wash
outgoing mail, but this temptation is balanced by privacy concerns of
their customers, who have no shortage of options when it comes to mail
providers.
As far as recipients' temptations go, would you also argue that refusal
to accept mail from open relays is somehow unfair to the operators of
those relays? If the operators don't like being ignored, they are free
to close the hole, which in this case means implementing RMX. This is a
feature which encourages adoption, not a bug.
JCL> Here's the condensed version:
JCL>
JCL> The sending and receipt of a mail is a contract between the sender and
JCL> the recipient. The definition and terms of that contract are
JCL> subjective to those involved. The use of external symbols and
JCL> referents in the contract, like domain names, is relevant to those
JCL> involved in the contract, not the referents.
JCL>
JCL> Mail, like all human communication, is an autonomous peer-to-peer thing.
JCL> Domain names and the rest of that are convenience trappings and
JCL> abstractions, no more.
I disagree; no contract exists, not even an implied one. In the case of
spam, the recipient specifically does not want it.
RMX enables a check, on behalf of the recipient, with an interested party
(the sending domain) which has both the ability and the responsibility to
certify that the message originated there. If the message proves to be
spam, the recipient is less likely to accept mail from that domain in the
future.
MR> Furthermore, if you can think of a reasonable alternative and provide
MR> a link, I'll include it.
JCL> <nod> I'm working on it. Its a rough space -- you've got three nodes
JCL> among DNS, the originating node, and emitted message, and establishing
JCL> validation creds for a message (not an SMTP transaction) without
JCL> requiring a shared secret between DNS and the emitting node is rough.
Keep me posted!
Best regards,
Mike
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg