Regulated Mail Transfer Protocol:
A novel protocol to incorporate user control over incoming mails
MOHD. FAISAL
IFTIKHAR ALAM
A.Q. ANSARI
Department of Computer Science
Jamia Hamdard (Hamdard University)
Hamdard Nagar, New Delhi – 110062
INDIA
Abstract: - This paper proposes a conceptual model of a protocol for electronic mail communication that effectively handles the problem of denial of service attack due to spam mails. The protocol restricts any mail from a non white-listed sender from entering the user’s mailbox and instead notifies him with a small sized request for acceptance of the mail, also the sender has to keep this mail in his own message store until the intended receiver responds to the request. This solution not only keeps unwanted emails away from the mailboxes but also discourages the sender from spamming around freely. The paper also recommends three models for effective utilization of the message store space. A reasonably comprehensive implementation mechanism for the protocol has been expounded in this paper.
Key-Words: - Spam mail, SMTP, RMTP (Regulated Mail Transfer Protocol), Message Store, Mail Reference Count, Request, Whit List, Sent-Box, Request-Box, and Mailbox.
- 1 -
1. Introduction
It is a very well known fact that emails are nothing less than a boon among the modern communication techniques but it is been claimed by many studies like [11] that spam mails are nothing but a bane for the users of email.
Though, email is undoubtedly a very effective method of communication these days but at times it can be quite vexing when one is confronted with so many unwanted emails where the recipients miss their important emails just because their mailbox space is often eaten up by these unwanted emails.
Our solution to this problem is inspired by the very way we manage the entry of various people in our home together with the assumption that an effective solution to this problem lie only at side of the sender who is sending unsolicited mails i.e. the sender of the unsolicited email should be discouraged to send any such mails. Here emails only from familiar email addresses (white-list) are allowed directly and every email from a new email address is first checked for if we want it to be in our mailbox or not. By doing so we want to give the user an absolute control over all incoming emails.
By applying this method the user of an email account can always keep his mailbox free of unsolicited mails because almost always the unwanted emails are from the email ids that are not known to the user and at any time when he is asked for accepting a spam mail through a request, he can out rightly reject it without letting it enter his mailbox. This way he will continue to receive emails from familiar email addresses (white-list) without any inconvenience
But the solution is not yet complete; the spammer can still discomfort the receiver by sending large number of requests to accept emails. The solution to this problem is to load the sender with the responsibility to keep the email, that he wishes to send to some user who does not have the sender in his white list, in his own allocated “message store” unless the intended recipient approves the request for acceptance of the email. If the request is approved, the email will be transferred in its entirety from the sender’s “sent-box” to the destination mailbox. Though by applying this method we cannot physically stop spammer from sending spams but if at all he sends some email that is not of importance for the recipient, the recipient will never approve the request for accepting this unwanted email and ultimately the spammer will end up with his own spam mails cluttering his own sent-box. Thus for a sensible spammer it will make no sense to fill up his own message store (actually sent-box) with his own spam mails.
Another advantage with this solution is that now the user will be safe against unwanted mails from known sources also, which is the case when some mischievous friend or any other known mailer starts to exploit his familiarity and fills the mailbox with the bulky mails.
2. Some existing solutions to prevent unsolicited mails and their shortcomings
According to a European union study [13] junk emailing is responsible for a loss of some 9.4 billion (US) dollars per year, and many major ISPs have complaints that spam adds 20% of the cost of their service due to extra traffic they have to carry. Though the most prevalent solution is to use spam mail filters or blocking function but both these solutions are insufficient and unsatisfactory. Also, while both of these measures are applied to keep unwanted mails out of user’s mailbox, the irony with these measures is, they have to be implemented at the receiver’s side while the spammer is never discouraged from sending unsolicited mails.
2.1 Blocking Function
It is used to prevent someone from sending email to the user, which means that the email messages from a specific email address (the blocked address) will no longer be delivered to the user account.
The first problem with the blocking function is that the user must know the mailer’s id in advance in order to block him. It is a complete failure in case the user is not aware of the email id of the person who might send him unsolicited mails in the future. Also it is not a feasible solution for a user to block spammers because spammers are continuously employing new email ids to deceive the user.
Another problem with the block function is, the user is never notified about the mails from the blocked senders, which may result in losing mails of great significance (because even the blocked senders may sometime send an important mail).
2.2 Spam Mail Filters
Spam filters are used to remove unwanted emails from the user’s mailbox automatically. Spam filters look out for mails from unknown sources (non-whitelisted mailers) and forbid the spam mails from entering the user’s mailbox. They identify these mails by exploiting the property of spam mails to contain certain phrases like “great offer” or “win a trip” etc. which are usually not used in normal communication. Other characteristic features of spam mails that can be targeted by spam filters are HTML color tags and that they do not contain personal information like first name etc. But spam filters are not the ultimate solution because of certain shortcomings.
The first problem with spam filters is that there might be some mailers who are not present in the white list but are as important to the user as those present in the white list. And there have been instances [12] where such “real” mailers were filtered out as spammers.
A typical shortcoming of the spam filter is its inability to filter out mails that do not qualify its criteria to be considered as “spam” but are somehow useless for the user.
Another problem that might appear a little unusual is the filtering of mails that despite being spam might be wanted by some atypical user.
3. The proposed solution: regulated mail transfer protocol (RMTP)
The above-mentioned limitations of the existing solutions to the problem of spam are the basic motivation for developing a new solution. The proposed solution is the design of a protocol that can provide user control over incoming mails as well as discourage the spammer from sending unsolicited mails.
3.1 Technological overview
The protocol has been divided into two stages: Stage I and Stage II. Stage I is based mainly on the existing SMTP [1,5] with a few additional commands, the entire mail transaction may complete in Stage I but Stage II is also possible in certain cases. The required commands for Stage I and Stage II are discussed later in the paper.
It is advantageous to inherit the characteristics of SMTP since it is the most prevalent mechanism of mail transfer for the last two decades and has been phenomenally successful in efficient and steady implementation of relay function of the MTAs (Mail Transferring Agents). And therefore, for an altogether new mechanism it would not be easy to survive against the leading popularity of SMTP. But due to certain inherent shortcomings of its lenient architecture for sending and receiving emails, it was necessary to incorporate user control over incoming mails, which would require a more regulated mechanism instead of the traditional SMTP mechanism.
3.2 The Requirements
To incorporate desired behaviour, the existing framework must accommodate the following new features.
Each user will have to maintain a “Sent-Box”, a “Request-Box” in addition to the “Mailbox”. The user space provided by the MUA (Mail User Agent) for the mailbox will now be shared among the sent-box, the request-box and the mailbox (see section 4: Sharing of Message Store).
Every user will have to maintain a “White List” also, which will contain the addresses of senders whose mails do not require any permission before being accepted in the mailbox.
Sent-box will preserve the mails sent to the recipients who do not have the sender in their white lists until the receiver approves or rejects the request, these mails will be referred to as sent-mails further in this paper. While the sent-mail is in the sent-box, the user can delete the mail but the corresponding requests will remain as it is in the corresponding request box(s). And now if the intended receiver approves the pending request, an appropriate error will be reported to the intended receiver. Otherwise if the intended receiver rejects the request the sender will assume as if nothing has to be done.
Request-box will contain the mail headers in the form of “requests” for acceptance of mails from non white-listed senders.
Mailbox will contain the emails from the white listed senders together with the emails from the non white-listed senders whose requests have been approved by the user.
3.3 Terms Introduced
3.3.1 “Request” for acceptance of the mail
Whenever the sender is not present in the receiver’s white list then instead of delivering the entire mail only a special message is sent to the receiver’s request-box. This special message is called the “request”. The request comprises the mail header, whose size is very small in comparison to the entire mail so the user need not worry about the consumption of his message store. This request informs the receiver about the details of the sender and the message and it requests a response from the receiver whether he wants to accept the mail or not. The mail header gives the necessary information to the user about the sender and the message (like sender’s id, subject of the mail, size of the mail and date etc.), so that the user can accordingly decide whether to accept the mail or not.
3.3.2 “Mail Reference Count”
Mail reference count attribute of the mail is the number of recipients who have not yet accepted or rejected the request. The initial default value of reference count is set to be the total number of intended recipients of the mail minus the number of intended recipients who have the sender in their white list.
The sender’s sent box contains sent-mails. In case of single recipient the mail is deleted from the sent box whenever the request to accept email is approved or rejected. But in case of multiple recipients the mail cannot be deleted from the sent box until all the intended recipients have approved or rejected the request since only one copy of the original mail created by the user is placed in the sent-box even if the mail is to be received by multiple recipients. To ensure that the mail is deleted only when all of the intended recipients have approved or rejected the request, the reference count attribute is needed. The value of this attribute is decremented by one whenever any of the recipients approves or rejects the request. The mail is “deleted” or ”moved” only when the reference count value reaches zero.
3.4 The Mechanism
The RMTP (Regulated Mail Transfer Protocol) involves two stages: Stage I and Stage II. Where Stage I is mandatory but Stage II may or may not be required for a complete mail transaction.
3.4.1 STAGE I
This is the starting stage of a new mail transaction. It is same as existing SMTP [1,5] but here RHLO is issued instead of HELO and also it has three additional commands namely SNPR, PVSB and SNRQ that are described below.
1.SNPR (sender present): <sender’s id<receiver’s id>
It checks the presence of the sender’s address in the intended recipient’s white list. It returns TRUE if sender is present otherwise FALSE. If it returns TRUE the mail is simply delivered to the intended recipient’s mailbox and the mail transaction ends, otherwise the next two commands PVSB and SNRQ follow.
2.PVSB (preserve in sent-box): <sender’s id<email identification no>
It is issued only when SNPR returns FALSE. It places the email in the sent-box of the sender. Only one copy of the original mail created by the user is placed in the sent-box even if the mail is to be received by multiple recipients. This command plays a very important role of loading the sender with the responsibility of keeping the mails, sent to the users who do not have the sender in their white-list, in is his own message store until the intended receiver approves the request. This will lead to a discouraging influence on the spammer because no spammer would want to clutter his own message store with his own mails.
3.SNRQ (send request): <receiver’s id<email identification no>
It sends the “request” in intended recipient’s request-box asking for a response (approval or rejection) from the receiver.
These commands can be issued only during the Stage I of the protocol.