Browse Prior Art Database

Method to impose a secure hidden route

IP.com Disclosure Number: IPCOM000030908D
Original Publication Date: 2004-Sep-01
Included in the Prior Art Database: 2004-Sep-01
Document File: 2 page(s) / 56K

Publishing Venue

IBM

Abstract

The method described hereunder applies to e-mail processing, more particularly with SMTP protocol, the object being to limit the possible risks during e-mail transfer. When a message is issued by a mail system user, the message could go thru different routes according to the configuration of the Message Transfer Agent (MTA). In fact a lot of SMTP Relay are used when a message in sent across oceans. The fact that a message may transit through several unknown SMTP relay servers has been recognized as a risk with respect to different aspects, as outlined below: · Privacy risk: if the message transits through a SMTP relay connected to the public Internet network, such a SMTP relay can store the message envelope information and then aggregate this information with others to build illicit Directory (spammer behaviour). · Service Level risk: if the message transits through a SMTP relay based on another transport protocol, or simply following other mail delivery service level policies, then there is a risk of mail delivery service level downgrade that the message sender does not want to take. · Security risk: if the message transits through a SMTP relay which is not operated by a trusted organisation, then the message sender may consider the risk of having the whole message spied by a competitor or simply a hacker. In order to get rid of the above problems and risks, the proposed invention provides an innovative method to guarantee the route towards the final destination and to secure the anonymity of the addresses. Furthermore a business aspect is surfacing in the mail system space as the transit of SMTP messages is starting to provide economic issues (handling mails in transit is clearly not for free and asks for more and more stringent resource requirements), so it becomes important to be able to impose routes when messages are sent

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Method to impose a secure hidden route

Principle

    The solution is based on the usage of the private and public key (Certificate), that each MTA has today to provide SSL connection. The principle consists to encrypt the route of the message and also the final receiver. The principle is that a MTA has just to know the address where it has to route the message to the next hop, but without knowing the whole route up to the final destination.

So the next destinations are ciphered with the public key of the MTA that has to handle the message.

260 270

    ne xt destination decryption

   ne xt destination decryption

280

destination encryption

250

   ne xt destination decryption

220 230

240

Sender MTA

A

202 203

MTA Relay

B

Deliver MTA

C

210

204

Deliver MTA

D

205

201

200

290

SENDER

Receiver

Fig 2

    This method extends the capability of the MTA relay or of the MTA delivery to allow deciphering of the next domain name or mailbox name to which the MTA has to send or deliver the message. Agent added in the MTA relay or deliver is a SMTP service extension and should be registered to Internet Assigned Numbers Authority (IANA).

This invention also extends the capability of the MTA sender to allow ciphering of predefined route The principle is that a relay MTA has just to know the address where it has to route the message to the next MTA server (either another "MTA relay" server or the destination "MTA Deliver" server).

So the next destinations are ciphered with the public key of the MTA handling the message.

Description

    When a MTA, decides to impose a secure route (source routing), it verifies if the first MTA to which it has to send the mail, supports the service extension able to decipher the next domain address. If the next MTA along the route does not support the destination deciphering, then a non delivery notification is returned to the sender. Else the MTA sender encrypts the route of the message as well as the final receiver address and then sends the message to the next MTA.

In our example a user (200) belonging to "domainA" sends a message to the recipient "receiver@domainD".

    After receiving the mail from the user (200), the MTA A (210) makes a lookup in the source routing table to retrieve the route to be used to reach the destination.

1

Page 2 of 2

* If the destination is not found in the table, then the mail is processed as usual leaving to relay MTA to choose the next MTA to propagate the mail. The MTA sender uses in this case the address of the recipient ("receiver@domainD" in our case) to route the mail.
* If the destination is found, then the list of...