Is it unsafe to allow apps other than Outlook to send email via the Exchange server?

Question

My application is a .NET Windows Forms client, one of whose functions is to allow the user to send personalised mailshot emails to opted-in recipients stored in the database.

The emails are sent using the .NET System.Net.Mail classes, from the client computer on which the application is installed, directly to an SMTP server within the client's firewall.

The customer secures this relay by:

• specifying the computers that are permitted to send the emails

and optionally by:

• specifying that the client application provides user/password credentials.

Of about 30 customers, one is unhappy with this arrangement on the grounds that:

• if the client machine became infected with suitable malware, it would be possible for the permitted computers to act as spam relays.

Now, I realise that in theory, malware that contained a password grinder could eventually break the user/password credentials. However, Outlook is already permitted on the client computers, so I don't understand why (given the existence of libraries such as Outlook Redemption), if allowing Outlook to send mail is safe, allowing my company's application to send mail is any less safe.

Would appreciate any pointers.

Edit:

Thanks for the replies so far... if I could add a supplementary:

I notice a couple have pointed out that Outlook doesn't use SMTP. However, neither does Outlook Redemption, a perfectly legitimate COM class library that allows, AIUI, authenticated MAPI communication to Exchange servers.

So if malware that had taken over the client machine could eventually grind out a password, and bypass (as does Outlook Redemption) the Outlook object model, and hence Outlook's security against programmatic access, could it not wreak plenty of havoc?

My question is really not so much about absolute safety - clearly that's never achievable - it's whether if there's a concern about getting malware at all, why would my authenticated application be any less safe than Outlook.

Answer 1

Your customer is not wrong - or rather, might not be.

If there is no password requirement, any user or app on that computer can send emails - whatever they want, as much as they want, to whomsoever they want.
But even more than that - they can send the emails from whoever they want. E.g. from the CEO, or VP HR, or...

So authentication should always be a requirement.
Moreover, though this may be out of your scope - their Exchange server should be hardened, to never allow unauthenticated connections.

Now, is a password enough?
It depends... can malware misuse your application to spoof and/or spam via their Exchange? (The answer is most probably yes - either via object models, DDE, .NET reflection, or even just stealing your app's password from storage).

Regarding Outlook, to the best of my knowledge, the object model requires user approval before sending mails from external apps.

Bottom line, you can make it more difficult, but not impossible - but then, you don't need to, since spam is already pretty cheap to generate even without you - you just have to make it hard enough.

Answer 2

If you wish to control who relays SMTP through an Exchange server, you have two options:

1. have a whitelist of permitted IPs
2. restrict relaying only to authenticated SMTP connections

If you've already got these both turned on, you've exhausted the technical controls in Exchange. If too much residual risk remains, you've got to look elsewhere.

Outlook doesn't (normally) use SMTP to send mail to an Exchange server, so the controls on SMTP relaying are irrelevant to it: but the general principle does apply to Outlook as well - that if someone takes control of a client machine, they could use it to send spam.