[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntbugtraq
Subject:    FW: Microsoft Exchange as a Spamming Host
From:       Mike Scharff <mscharff () EMAIL ! MSN ! COM>
Date:       1997-12-07 23:42:50
[Download RAW message or body]

Please note that this information is not accurate at all. Exchange 5.5
implements a few security features that will allow ONLY persons with
mailboxes on that server to utilize that IMS, or only persons whose from
field matches authentication, also requiring authentication on the IMS
period, all of these methods, as well as others, are available to alleviate
spam. Unfortunately, the problem does not lie with exchange, or Netscape,
or any of the mailhosts, there are inherent limitations in keeping
compliance with the current SMTP (Spam Means This Protocol) RFC's.

> -----Original Message-----
> From: Russ [SMTP:Russ.Cooper@RC.ON.CA]
> Sent: Sunday, December 07, 1997 20:03
> To:   NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
> Subject:      Microsoft Exchange as a Spamming Host
>
> Recent discussions with Dan Farmer have brought to light a problem with
> Microsoft Exchange (MSX) 5.0 and 5.5 Internet Mail Service (IMS).
>
> With the introduction of POP3, and now IMAP4, the MSX IMS must be
> configured to enable routing of SMTP (commonly called "forwarding" but
> termed "routing" in the MSX Admin GUI).
>
> When SMTP routing is enabled, MSX uses a table to determine how to
> handle inbound messages (inbound only, not outbound). This table can
> have value pairs indicating the destination email domain (i.e.
> ntbugtraq.com, rc.on.ca) and an instruction as to what to do with each
> specified domain (i.e. inbound, mail.rc.on.ca). The instruction
> "inbound" means that the MSX box should treat the domain as being
> resident on itself, when a FQDN host is specified, it means messages for
> the specified domain should be forwarded to the specified host.
>
> The issue comes with messages destined for domains not specified in the
> table. The most common table (when routing is enabled) simply lists the
> single domain name for the host with the instruction <inbound>.
>
>         <inbound>       ntadvice.com
>
> This configuration would permit the use of POP3 or IMAP4, as well as
> normal RPC methods of Exchange Clients, for access to the message store.
>
> If, however, a message is sent to this MSX box with a destination
> address of NTBugtraq@listserv.ntbugtraq.com this MSX box would happily
> accept the message and use its outbound message delivery configuration
> to deliver the message to its final destination (listserv.ntbugtraq.com)
> **regardless of who the sender was**.
>
> This makes MSX prime for SPAM delivery from anywhere, to anywhere.
>
> The easiest way to avoid this problem is to not enable SMTP routing
> (forwarding), but this means also not enabling POP3 or IMAP4, two of the
> most important features added in the last two revisions of MSX. Without
> routing, POP3 or IMAP4 clients would create SMTP routing loops with
> every message sent.
>
> MSX includes a feature called "Delivery Restrictions", which permits you
> to restrict who (mailbox) is allowed to originate messages.
> Unfortunately, this feature is only applied to messages that are being
> handled by the IMC. Inbound SMTP messages that are deemed to be routed
> (i.e. are not considered <inbound>) do not get processed by the IMS,
> they are routed (forwarded) prior to IMC and therefore are not
> restricted by "Delivery Restrictions". A message originated by a Spammer
> would never be analyzed by this "Delivery Restrictions" feature.
>
> There is, therefore, no way to use IMS in the role that Microsoft has
> documented it to be in. Documented in the on-line help under - Routing
> (Internet Mail Service) - "If your organization uses multiple SMTP
> hosts, the Routing property page enables you to designate the Internet
> Mail Service as the single point of contact to the Internet. Other SMTP
> hosts can be configured to forward all messages to the Internet Mail
> Service, where the Routing property page will route messages
> appropriately."
>
> If you followed this advice you will open your site up to being used by
> Spammers.
>
> Microsoft have been made aware of the problem. My recommendation is to
> avoid enabling SMTP Routing completely, and if necessary, consider some
> other SMTP handler in front of IMS. I would expect to see some method
> made available to prevent this exploit, but the only method I can think
> of (taking all SMTP messages into the IMS so the "Delivery Restrictions"
> feature can handle them) means a serious performance hit for MSX's Smart
> Host capabilities. It would also entail creating Custom Recipients for
> every foreign mailbox out there, something they tried to get rid of by
> introducing this "feature". Under some very specific conditions it may
> be possible to thwart Spammers by inserting an <inbound> SMTP routing
> entry for every top level domain in existence (i.e. .com, .gov, .au,
> .ca, etc...). Of course this would prevent MSX from being used as a
> Smart Host, and would prevent it from being used for POP3 or IMAP4
> clients, but it would permit the inbound redirection of a specific email
> domain to a known SMTP host without permitting Spam hosting.
>
> An API exists (CDO) for MSX which would permit the creation of a
> filtering mechanism that could check for certain conditions (i.e.
> Sendmail-like) and handle appropriately, but so far nobody has created
> such a utility that I am aware of.
>
> FYI, more than 25% of the NTBugtraq membership are running MSX and using
> IMS, but many are behind some other SMTP host. MSX 4.0 did not function
> this way and is therefore unaffected.
>
> Dan Farmer is currently working on a document regarding Spamming,
> specifically how best to prevent it. This document is not yet complete,
> but if you'd like to be notified when it is please send a message to
> mailto:Spam@rc.on.ca and I'll notify you when its done (I doubt Dan
> would appreciate a bunch of messages asking for it now).
>
> Cheers,
> Russ Cooper
> R.C. Consulting, Inc. - NT/Internet Security
> owner/moderator of the NTBugtraq Mailing List

[prev in list] [next in list] [prev in thread] [next in thread]