william(at)elan.net wrote:
The reality is that im2000 is generally alot better approach for email
infrastructure where you do not expect that every email would be
delivered...
I'll just throw in my own writeup of IM2000 benefits, which is at
<URL:http://meta.ath0.com/articles/2006/01/22/spam2>
der Mouse wrote:
I like this, for normal mail transport. I don't see it as being of any
particular anti-spam use, though; spam will simply be sent without
using it, the way it is today. (Given all the usual deployment issues,
it'll be a long time before anyone but the most lunatic fringe can
afford to reject mail not sent using it.)
True, but you can use lack of IM2000 as another indicator of likely
spamminess.
Douglas Otis wrote:
When the data is stored at the sender, no intermediary is able to
"filter" this information based upon signatures.
That's not true. There are HTTP proxies that filter for malware.
Of course, a URL could be required to use a host name which would
exceed the protections of an SPF IP address authorization scheme, but
without the serious risks. Within the underlying transfer protocol,
simply require the use of host names. : )
If it were me, I'd require HTTPS and an SSL certificate. Anyone wanting
to run their own mail server can afford $30 a year.
Tony Finch wrote:
- it pushes the email burden back onto the sender - for real, not like
many anti-spam companies claim.
What burden? Spamware generates the junk email on the fly.
The bandwidth burden for starters. And I suspect it's not easy to set up
a web server that can take a few million hits just after 9am on a Monday
morning, still remain anonymous, and change its domain name, IP address
and SSL certificate each spam run.
- it makes the sender easier to track.
Moreso than the web site URLs in existing spam?
Plenty of spam doesn't have web URLs.
mathew
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg