Re: IM2000 RNASP -- identifying message stores to recipients
Charles Cazabon <[email protected]> Thu, 11 Mar 2004 13:09:47 -0600
| Newsgroups | gmane.mail.im2000 |
|---|---|
| Message-ID | <[email protected]> |
Jonathan de Boyne Pollard <[email protected]> wrote: > > We could turn [ServiceLocation] from a SEQUENCE into a CHOICE. If domain literals are kept, this would be my preference. > On the other hand: What you say above does partially attempt to have things > both ways. Either the reason that the ability to use literal IP addresses and > port numbers makes things easier for UBM senders is that forcing the use of > domain names is a non-trivial hurdle for message store owners to overcome, Not necessarily a non-trivial hurdle, but a hurdle. The problem is the whack-a-mole game, which is slightly different in each of these two cases. If only domain names are allowed, the whack-a-mole game goes like this: 1) Spammer buys a domain for $6, arranges for DNS service, publishing SRV records for MSRAP. 2) Spammer gets (perhaps zombie) RNASP clients running delivering notifications to everyone-at-large. These contain a reference to the domain in (1). 3) People recognize this domain is a spam source, and blacklist it. It doesn't matter if the spammer moves the message store around -- to get his mail through, he has to return to (1) and buy another domain name. If domain literals are allowed, he'll use that to direct recipients to his spam message store. People can't blacklist it by domain; blacklisting it by IP address will result in false positives when other, innocent parties are assigned that IP address. It costs the spammer nothing to move his spam message store around and change his notifications to point to it. There's the difference. > or message store owners will not find it onerous to have to use, and to > publish data about, domain names and therefore this doesn't really affect > UBM senders at all and doesn't open up an avenue for greater abuse. Not necessarily onerous. If SMTP were a pull protocol, it would be the equivalent of not allowing sender addresses of the form <spammer@[1.2.3.4]> because of the increased difficulty of mapping addresses to responsible parties. Charles -- ----------------------------------------------------------------------- Charles Cazabon <[email protected]> GPL'ed software available at: http://www.qcc.ca/~charlesc/software/ -----------------------------------------------------------------------