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/
-----------------------------------------------------------------------