A few months ago we were getting repeated requests for a feature we had not considered ourselves. When scanning to email or fax from the MFD the experience for both sender and recipient is counter-intuitive; recipients get an anonymous email from This e-mail address is being protected from spambots. You need JavaScript enabled to view it with no practical route to reply and senders have no record of the scan being sent.

To bring this more in line with the normal experience of sending email we didn’t really need to do much more than reconfigure features we already had. Firstly, make the email appear to come from the sending user and, secondly, to place a copy of the scanned document in their email Sent Items folder.

There are some solutions that already do this, often using IMAP to insert a copy of the email into the user's mail-store. We considered this approach but discarded it as we didn't want to implement an IMAP client just for this and also felt it was a little restrictive as you can only perform the copy on accounts you have IMAP access to. Another method would be to send all mail via a dedicated mail proxy that could insert the Sent Items copy into people’s mail accounts. The main problem with both of these is the need for either system to hold the user's mail credentials in order to log in as the user but there are others such as infrastructure costs that make it unwieldy.

Our solution is a low tech one, making use of features standard to most mail clients. When our machine interface creates an email it can now optionally copy the sender's address to the BCC field and the mail server will deliver it to the To address and to the BCC address. This feature is also available when scanning to fax, which uses email as the transport mechanism.

At this point the user will have a copy of the email delivered to their inbox and we need it in the sent items. This is achieved by creating a rule that moves emails sent From themselves to their sent items. Many users mail themselves now and again so we don't want all mails from the user copied to their sent items. To stop this we have changed the email header to add a name the for mail client that sent the scanned document (X-Mailer = m3i Email Service). This can also be added to the rule so that only emails sent from a machine interface are moved. There is one further refinement, we also added the serial number of the machine that performed the scan (X-m3i-Serial = A123456789) so that users can add this to their rule and direct the emails as they see fit.

One downside to the approach is although, most mail clients (and servers) support rules there is no common format for them. This makes it difficult to programmatically add the rule, so some configuration is necessary on the client. However, many clients do allow the importing of rules or using domain policy to apply them. The need for rule creation was considered to be simpler and more secure in comparison to supplying email credentials to some external system or MFD.

This lightweight solution has one further benefit, as long as your From address is acceptable to the outgoing mail server it can copy the email to any account, regardless of the mail protocol used.

Essentially, the solution is transport, server and client agnostic providing you have mail routing rules somewhere in the process. The feature is made completely transparent if an organisation uses User ID to log the user into the MFD, in this case the from address will be automatically set as the user logs in.