I am new to this list, but thought I would see if I could contribute
a bit here or there.
I have been programming for quite a while(30 yrs or so), worked on every
thing from simple applications to device drivers.
I do have some questions about the solutions/ideas talked about. I
was wondering why not have the "TO:" field be required to be verifiable
from each stop. I know this would increase the bandwidth requirements
of each email, but it would also prevent unidentified emails (99% of
the spam I get are unidentified). If the MTA would validate on
arrival and unvalidated email gets rejected, you at least have an identified
user to squash when spammed.
Next, I do think you need federal legislation that creates the email
equivalent of a "do not call" list that any legitimate bulk emailer
must consult. I think it must be accepted that bulk emailers are
going to be around, will operate with/without your consent...
The problem I see is that on the sending end, anyone can create a
bulk email business for virtually no cost.
I personally use a whitelist for most of my expected email, but expect
to get several that are unexpected, but not spam. The unexpected are
filtered, I get false positive and false negatives, I still have to
get rid of the junk...(interesting enough, 99% of my spam is in html
email which I never read, if it gets to me as html and valid I tell
the person to use plain text and add them to my whitelist).
Any solution that requires users to change their tools/upgrade/do something
different is OK, they have the incentive to do it so as to
get rid of spam.
Any solution that requires an ISP to change/upgrade/do something different
is much less likely to happen since you still have open relys out there
that haven't been updated in years... If it costs money it aint
gonna happen. Besides, my ISP could get into trouble if they started
blocking emails I wanted...
The problem has to be solved on the sending end or you do not have
a solution. The only ideas that seem to make sense are the idea of
validating the sender at each hop (then as more and more MTAs get
updated to do this, the sender is better identified and can be blocked)
and the idea of estamps.
Tony Preston
Systems Engineer - AS&T Corp, Division of L3
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg