We're getting further off-topic for the Declude list I think. 
Apologies again.

| The personal messages are the most difficult and becoming 
| worse.  They are random and infrequent.  They are often among 
| the most important messages.  Individuals have an 
| unbelievable number of private e-mail accounts that they 
| seemingly use with little organized thought.  And some of the 
| messages are SPAM except for the fact that the user intends 
| to send them and the recipient wants them.  A very, very 
| difficult problem.

Thanks for all that... I think you're right on all counts. This last one
is a real bugger - however we have some dynamic systems coming that
should help this somewhat. I believe Scott is thinking of putting some
similar things in place for Declude, or at least that they are on the
wish-list.

Two methodologies -

(1) Legitimate messages contain some "pass code" that can be white-coded
by Message Sniffer, thus allowing them past no matter where they are
sent from. This could be some standard part of the other parties
signature (their name, or phone number for example), or something
special that you gave them. (If you're a Ham Radio fan, this is like a
PL tone for email.)

(2) The system may presume that if you have sent a message to a
particular address that this address is allowed to send messages to you
- with some intervening metrics to avoid abuse - such as recording also
the source and destination networks. This one is probably ok unless the
message comes from a completely random source.

In any case, businesses using spam filtering should have a method for
handling "unwanted lockouts" such as maintaining an unfiltered contact
address that has very limited filtering so that customers/contacts
always have an address they can go to... or a contact form that allows
the contact to send their first query to the company and registers the
sender's email address with the filtering system so that they can be
sure to always get through. If these are links on the company web site,
they can be randomized aliases that are generated daily and then thrown
away. The alias would point to an underlying account that is never
publicly posted. Anyone clicking on the "Contact Us" link will get
through with the "address of the day"... any spammer harvesting that
address has polluted their database with a bad address that, after a
while, can be used to detect spammers (no legitimate contact would use
the address after some reasonable period of time).

Another mechanism like this would be an address on the system where
internal users can BCC or forward a message to/from a new contact such
that the system collects their addresses and gates their email from then
on - allowing them into the "circle of trust". Mechanisms like this can
be easily implemented with only minor procedural changes and can have a
profound impact on spam reduction by allowing for very strict (or even
closed) filtering. 

For example, in a sales organization it is likely that notification of a
new customer or lead would be forwarded to some sales manager. If that
manager's address were an alias the copied the message to the "gating
address" on the system then white listing the new lead would be
transparent and automatic in nearly all cases. 

We plan to offer features with our online database to automate some of
these mechanisms. Many could be implemented now with Declude and a
little bit of programming work to manage white & black lists... within
limits, of course.

_M

PS: Note that the model for (1) is also applicable to a customized
NO-SPAM system which uses computer generated headers (convolution codes)
to authenticate senders and receivers. Sniffer would then gate messages
with legitimate pass-codes while diverting all other traffic. Clients
and MTAs that have been allowed into the "circle of trust" for a
particular organization would produce recognizable one-time codes in
their message headers so that other participating systems in the circle
would not filter them out. Systems outside this circle would take their
chances with the filters or simply not be allowed to send their
messages. Convolution codes are used once and thrown away so that nobody
can catch one and use it to gate their spam or other malware into the
system.



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Reply via email to