On 1/22/06, Bart Schaefer <schaefer at brasslantern.com> wrote:
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?
Under the current email system you can't revoke your address, you just have to suck it up when you get spam. If you desperately don't want to revoke a sub-address that you gave to a machine months ago then you don't have to. The multiplicity of sub-addresses makes it less likely that any one would become compromised. Before I revoked the sub-address I would notify the "machine." If the machine belongs to a trusted domain that has upgraded its software then the sub-address can be deactivated without fear of being cut off.
If a trusted domain was not established and the machine email came from an reputable business that was sending an important email then I would hope that the reputable business would spend the absolutely trivial amount of expense need to decode the CAPTCHA and return the email.
I'll also add that I think it will be a relatively rare event for an sub-address to be revoked. The person who created this sub-address system:
reports that in 14 months of use he has only cancelled 2 sub-addresses.
Almost all of my web site is devoted to discussing challenges but I believe it will be a very rare occurrence for anyone to actually encounter one.
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?
You'll have to look at how existing sub-address systems such as Zoemail, Reflexion, and Traveler do it and extrapolate from there. Different types of email systems will need different types of software upgrades.
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?)
I don't know, but I sure that AT&T ain't gettin' rich off of Zoemail.
} 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.
It's more of a Vacation message than a Challenge.
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.
How does the spammer figure out who is on your white-list? The white-list only contains the addresses of your personal contacts.
I also stated that ISACS would work synergisticly with filters, and DKIM is a tool used to enhance a filter.
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.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
The spammer will spam
Joe at domain.com knowing that Joe will not receive a single piece of spam? 95% of this spam will be filtered immediately and 5% will go towards victims. If the victims filters are set to filter out ISACS bounces that don't correspond to recently sent emails then 0% will reach the victims. If the victims filters have not been updated for ISACS then the filters will detect the words "Cheap Viagra!" in the bounce and another 95% of the remaining 5% will be filtered. I don't see the motivation.
- "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.
Existing sub-address systems (as best as I can determine from outside sources) rarely need to deactivate sub-addresses, and ISACS is designed to make this an even rarer occurrence. Any sub-address recently distributed to the stranger should be active. But yes, you are right - people can still refuse to handle resend their email.
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 will defer to other knowledgeable members as to if these are insurmountable issues. I suspect not, but I will defer to the group consensus.
- "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?
My description was more appropriate for webmail systems, but yes, email user agents will need to be updated to use ISACS.
- "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?
Senders at trusted domains that have been updated to automatically resend ISACS bounces (see Figure 5 from my website) will never need to use a sub-address. I consider this a tremendous advantage. Please see the last section of my web page where I talk about the evolution of ISACS.
Would there be some odd class of domains
that allows spammers to send mail but not to harvest?
Every trusted domain can still send spam. A trusted domain is simply one that prevents harvesting.
For webmail this is true. Email user agents will need to be reprogrammed to recognized the bounce seen in Figure 4 and act on this info to automatically update the address book.