At 1:18 PM -0400 2003/10/23, David Maxwell wrote:
That's fine, but keep in mind that this has collateral damage
consequences.
It's my choice to accept those consequences - it's _my_ consent
decision.
That's fine -- up until the time where you tell other people that
they should be doing the same thing.
No, I'm suggesting that other people should be able to make that choice.
You seem to be arguing that recipients shouldn't be allowed to refuse to
consent to messages frmo anonymous senders.
Also, I never saw an answer to my question - "Are your activists sending
to recipients to whom they are known, or are they sending to random
recipients?"
If you want to insert lit explosive devices into your body,
that's one thing. But when you start encouraging other people to do
the same, that's totally different.
I think that if I were a bit smarter, I would accept that as close
enough to a Godwin's law offense that I would cancel this message.
That's not an abuse of DRIP. DRIP provides a layer upon which I can add
a white/grey/blacklist by domain. Without DRIP (or RMX, etc), I cannot
whitelist by domain, since spammers can forge spam claiming to be from
one of the domains I whitelist.
They could do that anyway. Remember the previous discussion of
DNS cache poisoning? Even if your servers are immune to cache
poisoning, what are the odds that the advertised nameservers of all
your whitelist domains are also secure?
A DNS server being compromisable is an implementation flaw, not an
infrastructural one. It's also more difficult than forging an email
address is today, thereby raising the bar for spammers.
Many of the viruses forge email source. If they didn't, I could easily
contact the sender and tell them to cleanup their machine.
Just forge the username. Unless you contact the system
administrator at that ISP and get them to match the username against
the IP address at that particular time, you'd never know (that's
assuming they have accurate logs for that time, or that they're
willing to do this for you since you're not a paying customer). Or,
forge the username within any of the other domains which are hosted
by those machines.
The later would be difficult for a virus to 'know'. The former would
still leave me with a good guess as to whose address book I might be in
- and at the very least, lets me contact the ISP who I know can do
something about it, with the information they need (source IP and time
of connection) so that they can inform the virus-infectee.
Of course, another issue with open caching/recursive servers is
that you can get anyone in the world to effectively host your domain
for you, and combined with wildcards they could appear to be hosts
for virtually all domains on the Internet.
I don't understand your example.
I'm not rejecting the mails in the SMTP phase - so the RFC specs are not
relevant - however, the fact that I cannot implement
white/grey/blacklists leaves content inspection as the only method to
identify spam. That 'guesswork' takes a lot of CPU time, and gives me a
very non-deterministic answer anyway.
You're going to be forced to do that anyway. You're just going
to force the spammers to get that bit more crafty to by-pass your
so-called protection mechanisms.
Right, it's raising the bar, and it's also enabling other tools.
As an example:
(All the following is with the exception of point-to-point user
verification, such as PGP signed messages.)
Without (verified) domain names, you can't have verified email
addresses.
Without (verified) email addresses, you can't have reliable user based
whitelists.
I believe that for many users, a short whitelist would be a highly
practical solution to the spam problem. It wouldn't be for myself,
personally - but for my mother, and my aunts...
Any white or black listing proposal which doesn't address the need for
authentication of the list compared data may be worked around.
David
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg