ietf-asrg
[Top] [All Lists]

Re: [Asrg] Unique innovations made to anti-spam system

2006-01-22 19:02:13
On 1/22/06, Bart Schaefer <schaefer(_at_)brasslantern(_dot_)com> wrote:

On Jan 22,  6:05pm, Michael Kaplan wrote:





} ** [Malware] is an argument *for*, not against ISACS. All of the
} contacts of the person infected with malware will be able to identify
} the source of the security breach based on the sub-address.

Again, perhaps.  This assumes that all contacts have "personalized"
subaddresses.

I expect you to say that this will be true because the correspondent
receives an automatically-generated subaddress in the first contact
between the ISACS user and the correspondent -- but if the correspondent
is also using ISACS, what address was originally used for that first
contact?  At least half of the users of the system must begin in the
state where they have either the "Joe^lucky" subaddress or one obtained
from a third party -- or where they have no subaddress at all and must
undertake to update their address book upon challenge.


Soon after you've used ISACS many of your contacts will have personalized
sub-addresses, so deactivating Joe^lucky will be intrinsically less
disruptive then when Joe(_at_)domain(_dot_)com was deactivated.  Joe^lucky can 
also be
deactivated in the same stepwise manner over a month or two just like
Joe(_at_)domain(_dot_)com was deactivated.  Some of the correspondents that 
were given
Joe^lucky will have already transitioned to personalized sub-addresses as
all subsequent emails from the ISACS user will contain personalized
sub-addresses in the "From" field.

Also of course if you've corresponded with this account then that account is
white-listed.

The total neophyte may rely on one custom sub-address "lucky," but many
slightly more experienced ISACS users will likely have 2 or 3 custom
sub-address, once again decreasing the impact if one is compromised.
With ISACS neophytes get a chance to make sloppy mistakes like posting their
address on the internet; they have a chance to learn.

If two correspondents are using ISACS then their domains are certainly
trusted.  Use of a sub-address would be completely unnecessary in that case.

I will concede that disruptions will occur, but the severity of the
disruption will decrease over time.

And I'll repeat my mantra of how challenges will vanish as trusted domains
and the relevant software upgrades proliferate.


} I still don't see why bounce spamming is preferable to directly
} spamming users.

Using bizarre HTML encodings to spell out words vertically or diagonally
or to represent pornographic images as ASCII art isn't preferable to
directly displaying the words or images to the user, either, but both
are techniques that spammers have employed.  You're postulating a
spam-prevention system and then wondering why spammers would attempt
to circumvent it?


Sorry, I still don't follow what you are describing.  I don't follow how
sending bounce generating spam to an ISACS account circumvents the ISACS
security.  Or is this somehow helping to spam non ISACS users?


When judging this system one should take its annoyances into account, but
please balance that against its benefits.  I often hear the refrain "We
won't end spam until we completely rework the SMTP architecture"  following
by the standard response "yes but there is no way to do that."
In the short term I believe that ISACS will provide an impressive degree of
immediate benefit to its users with a tolerable level of annoyance.  But I
also ask you to look towards the long term.  ISACS *can* be superimposed
upon current email architecture.  ISACS can proliferate to more and more
users, and nearly every domain can be entered into to database of trusted
domains.  As ISACS grows it becomes more effective and less annoying.
Now picture the day when ISACS is almost universal, and nearly every domain
is trusted.  No one will every have to deal with a sub-address or a
challenge.  Efficacy would be extreme, and annoyance would be almost
non-existent.  At that point could ISACS be the FUSSP?  Is there any other
way to achieve the FUSSP?

Yes we should consider its annoyances, but we should balance it out against
its short term and long term promise.

Thank you,
Michael Kaplan
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg