On Jan 22, 10:33am, Michael Kaplan wrote:
}
} With ISACS fully functional email addresses are distributed. Receiving
} mail from machines or unknown third parties will occur with that same
} ease that it does today.
What happens when the address that was handed out to a machine becomes
compromised and has to be revoked? Who/what keeps track of all of the
addresses that have ever been handed out and to whom, and who provides
the means to update all of them to new valid subadresses?
And, minor quibble, but how does this become widely deployed at little
or no cost, given that AT&T has apparently patented the subaddressing
technique? (For that matter, how does Reflexion get away with it?)
} If anyone out their knows how I can amend my web page so that this
} confusion with C/R doesn't occur then let me know.
I don't think it's possible, because ISACS employs C/R techniques. In
"phase 1" everyone in the whitelist will receive an automated reply,
which is equivalent to a challenge even though they aren't required to
respond.
In "phase 2" you say that "Email from white-listed correspondents will
continue to always be received ... only non-white-listed correspondents
who attempt to use a deactivated sub-address need" [to react to the
challenge]. However, unless you combine ISACS with something similar
to DKIM, spam that forges the address of the whitelisted senders will
also continue to be recieved.
You also say "The entire content of the stranger's message is now being
stored in the stranger's email inbox. It is waiting to be resent."
This presents an obvious recipe for a spammer attack:
- Discover the "base" address (Joe(_at_)domain(_dot_)com) for a fairly large
number of ISACS users by watching for ISACS autoresponses to an
ordinary spam run or a deliberate probe
- Launch a spam run of several hundreds of message to each of the
known-valid base addresses, forging the real desired targets of
the spam as the senders
- ISACS challenges containing the spam pour into the mailboxes of the
intended victims
This can also be mitigated by using DKIM-style authentication to avoid
sending challenges for forged mail. (I'm not normally much of a DKIM
advocate, but any "mailbox protection" system that employs automatic
responses without some kind of forgery detection is flatly unworkable.)
I disagree with John Levine that "retrospective authentication" is a
flaw in this system -- DKIM is an assertion that the sender is who he
claims to be; the ISACS subaddress is an assertion that the sender has
been given permission to contact the recipient, whether or not the
sender is who he claims to be. However, neither of those alone is
sufficient.
A few other remarks on the manifesto:
- "The stranger decodes the sub-address. The stranger then copies and
pastes his bounced message into a newly composed email message. The
email is successfully dispatched using the sub-address."
This is a naive statement on several levels. First, the assumption
that the stranger is willing to bother decoding the sumaddress, and
won't simply delete the challenge and take his business elsewhere.
Second, that the bounced message is something that can be copied and
pasted, i.e., not a complex multipart. Third, that all transports
involved can successfully transmit the original message, undamaged,
in both directions, without running afoul of various filtering and
size limitations.
I suppose this is all meant to be worked out during "phase 1" also.
- "Eventually the stranger's email provider can update its system so
that these bounces are even easier to deal with. ... The server
alters the email" [to turn it into an interactive form].
This seems to assume a webmail system, because otherwise you'd be
talking about putting this capability into email user agents, not
servers. If the UA is assumed capable of dealing with this, why
not build it in to the system that sends the challenge?
- "A central database of trusted email domains will be established."
If you postulate a global reputation system for trusted domains,
where is the added advantage of requiring senders at those domains
to use subaddresses? Would there be some odd class of domains
that allows spammers to send mail but not to harvest?
- "The address book of Stranger(_at_)TrustedDomain(_dot_)com is automatically
updated"
Another apparent assumption that all email management, down to the
user's personal information, resides on some kind of centralized
server at every interesting domain.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg