When Protocols outpace Chipsets, the Ricoh MPC 2050 case

It is a recurring phenomenon, in the IoT era, for network devices to be required to send emails and have access to SMTP functionality.

Thus, most device manufacturers attempt to follow through and implement the contemporary security protocols while designing and when firmware patching is possible.

However, only so much can be done by firmware updates on aged chipsets, whereas communications security protocols keep evolving, have their vulnerabilities exposed, depreciating, and getting replaced.

So how do you proceed when such a device finally shows its age?

We were called to resolve such a case when a domestic ISP finally decided it was time to upgrade its mailing services to TLS 1.2. This caused a broad range of all-in-one network printer/scanner/copier devices, used in corporate environments, to be unable to use any of their “mail to…” services as the TLS protocol was not possible to be implemented.

The Work-around.

The client employs a Windows-Server-based infrastructure.

A Windows Server VM was setup and IIS Services, SMTP Server and Telnet client features were installed.

TCP 25 (RFC5321) port was opened.

Minor nitpick: As IIS 8 cannot manage SMTP services, for the rest of the tasks we used the IIS 6 embedded console.

We proceeded with configuring the allowed hosts that can connect to this SMTP server:

Loopback IP and the address of the afflicted network device (in our case a printer/scanner/copier)

Smarthost must be configured next. We used the corresponding mail server of our domestic ISP and the available corporate mail account with enabled TLS.

For the last step we returned to the management interface of the All-in-one device and on the SMTP configuration page we replaced the SMTP server from the IP of our ISP to the IP of the newly-setup Virtual Machine.

The story’s log

Ricoh MPC 2050 incorporates a scan to email functionality many years now, but does not support sending out emails over SSL, therefore we introduced the idea of putting a local smtp server in the network that could handle “unauthenticated” open relay and submit on behalf of the sender through the ISP, in our case Cosmote.

Picked up a vm with low resource consumption footprint and Installed the IIS 8 role and SMTP server feature.

IIS 8 cannot manage smtp service, so we used the IIS 6 embedded console.

Configuring hosts that can connect to this smtp server: 127.0.0.1 and the MFP MPC2050 IP address.

Configured as smarthost the mailgate.cosmotemail.gr using the customer’s email account [email protected] and enabled TLS.

Opened up port 25 TCP incoming on the VM’s windows firewall.

Changed the smtp server on MPC 2050 from the resolved ip of mailgate.cosmotemail.gr to the VM ip address 192.168.2.26.

Unless an IP spoofing is made, the VM’s SMTP will never send out emails of this kind.

Now how to test the setup? We are not there, and we cannot scan.

Testing with the Pickup directory: You can compose a simple e-mail text file (with no extension!!!) based on the SMTP specifications (RFC 822).

Here is the content of a sample text file typed in Notepad:

From: [email protected]

To: [email protected]

Subject: testing

This is the test message body.

Simply copy or move the text file into the Pickup directory where SMTP was installed.

With the above configuration the SMTP service will periodically check the Pickup Directory (%systemdrive%\Inetpub\mailroot\Pickup and %programfiles%\ Exchsrvr\Mailroot\Vsi 1\Pickup if you have Exchange installed.) and will attempt to deliver any messages found in the directory.