Journal: A Mail Affair

A lot of talk has been going on about SPAM of late. Many proposals have been made, and some indeed show some possible merit. Most directly focused on has been Microsoft's offering, something known as Email Caller-ID. The concept, of course, stems from the common telephone service, which allows the answering party a good idea of who might be calling.

The email equivalent, of course, is the ability to verify that the incoming MAil Server's IP Address is indeed a valid outgoing email server for the party sending the mail, thus providing insight into identity of the original sender. This information will then be processed through some list of rules which will hopefully allow our email servers to better identify spam from ham, or the "good stuff".

The nitty gritty of this approach is to identify who the last email hop is, before the mail hits your company's inbound email servers. The value this provides can be quite helpful in determining who the originator of email is. This type of technology is not without merit, although probably without teeth. The end result of being able to identify approved email from a company does not limit their spam in itself. It does place some responsibility on the sending party to identify only which servers their outbound email should be coming from, and there exists in that a certain accountability. Limited, but some.

There are several issues with Caller-ID's approach, both technical and otherwise, which raise the question of feasibility. Caller-ID calls for a change to DNS (excuse me, an extension), and that everyone run it... The changes don't stop there. All MTA's (Message Transfer Agents, eg. Sendmail, Postfix, Exchange, etc....) on the border of your network will have to be updated to support Caller-ID. And finally, some actions will need to be defined, either techincal or social, in order to deal with the SPAM problem once the originators have been identified. The real question is this: Is this really worth the effort and wait. When would Caller-ID find its way into production? Beyond that, would different implementations work together? Do the benefits outway the costs? Remember, we're not just talking about a change in SMTP, but DNS.

This article is not an effort to bash on Caller-ID. I've already mentioned that there are technical merits to this type of technology, although the teeth will have to come elsewhere. But perhaps there is a better way to get similar results, with additional benfits, and less cost. Consider the remainder of this article as a non-corporate funded concept for Email Caller-ID. I have no hidden agend or products to sell (well, not that this article promotes). Perhaps this type of proposal would be best placed in an RFC (Internet Request For Comments, where most of what you do on the Internet was fathered) but I am not nearly intelligent enough for that arena, nor do I have a corporate sponsor to put after my name, nor the buy-in of other RFC-writers. Perhaps someone reading this with a great deal more intelligence than I will be inspired from this article to write an RFC. If there are any blaring holes in my theories, please feel free to comment.

DNS-TLS

In the current generation of MTA's there exists a standard for securing communication and identity-verification known as STARTTLS. Many MTA's, including Sendmail and Postfix, provide this functionality out of the box. STARTTLS is an SMTP implementation of TLS, which is short for Transport-Layer Security and has been accepted as more secure than SSL. Both communicating systems have a Public/Private Key and certificate which are used to encrypt the data. Assuming the key/cert combo was generated using a trusted Certificate Authority (CA) these certificates may also be used to authenticate one or both systems.

The weakness in the current rendition of STARTTLS is the reliance on the public key infrastucture (PKI) specifically with regards to the "Trusted Certificate Authority". The Authentication piece of STARTTLS fails immediately if the certificate is self-signed or the authority chain is otherwise obscured from verification. There is already a trusted authority, at least good enough for our purposes, known as Domain Name Services (DNS). DNS already supports the use of KEY records to store Public Key information. FreeS/WAN, a popular IPSEC implementation has been pushing the use of DNS KEY records in an attempt to simply and affordably provide Public Keys for some time. The DNS KEY record should provide the proper information to authenticate the other system. The final piece to this puzzle is the the MX record. Each outbound email server would require a Mail eXchanger (MX) record in DNS, using a high number for preference (the lower numbers are used first). So long as the MX priority is the highest, the only traffic which should cross the servers would be outbound email and spam-attempts from the outside which attempt to target the "test" servers in hopes that they are less protected. If outbound SMTP servers are different from inbound servers, outbound servers may be locked down or firewalled so no inbound SMTP would be allowed. If all other Mail Servers were offline and mail started failing at the outbound servers it would be no different than having no inbound servers at all, which would have been the effect anyway.

The most important key here is that the functionality is already in existence and in wide deployment. Only the code which acts upon this information remains to be written. The exception which would require writing is the server portion of the TLS specification, allowing the use of DNS KEY records for authentication. The corresponding rules for handling the mail based on its identity could be written into the MTA directly or sit as a filter or some other external program in the email chain.

The process would work as follows:

*) The originating server would have an MX record in DNS.

*) The originating server would have a valid certificate and a KEY record registered in DNS

*) The originating server would begin a TLS session with the receiving server using STARTTLS

*) The receiving server would validate the identity of the originating server by checking its published DNS KEY record for its public key.

*) The receiving server would then verify that the originating server is authorized to send outbound email by verifying the existence of an appropriate MX record.

*) Validated email ownership would be recorded in the email as an additional header, such as X-VALID-SENDER which would either = no or = yes and the details would follow.

*) Whatever logic required would be applied thereafter, most likely before delivery. Perhaps the MTA would be configurable to reject with a message explaining that only mail from other such servers was accepted.

The important part is that most everyone could comply with the sending end of this specification with currently available software, most often without any monetary investment. The receiving end could be implemented at the convenience of each company/user wishing to use the new functionality.

DNS-PKI

One other potential method of authorization differs slightly with different benefits/costs. In this other case, STARTTLS is not used, but instead the outbound SMTP server would be configured to sign the messages using its private key and the resulting inbound SMTP server would verify the validity of the signed message against the signing MTA's Public Key, stored in a DNS KEY record. Authorization would still be validated by an appropriate MX record. The benefit of this method would be that the authorized MTA would not need to be directly communicating with the validating MTA. Either the authorized MTA could be higher in the chain before leaving one network or the validating (receiving) MTA could sit farther back in the chain of MTA, allowing for third-party scanning systems or other special-purpose MTA's. The drawbacks include the inability to include encryption in the specification, and hope that STARTTLS or SMTPS will be used in the process. Also among the drawbacks is the fact that this approach requires changes to both the sending and the receiving MTA's, not only the ones wishing to make use of this functionality.

The process would work as follows:

*) The authenticating server would have an MX record in DNS.

*) The authenticating server would have a valid certificate and a KEY record registered in DNS

*) The authenticating server would sign the outbound email using its private key.

*) X number of MTA's could then route the email to it's destination server

*) The validating server would validate the signature and identity of the authenticating server by checking published DNS KEY record for its public key.

*) The validating server would then verify that the authenticating server is authorized to send outbound email by verifying the existence of an appropriate MX record.

*) Validated email ownership would be recorded in the email as an additional header, such as X-VALID-SENDER which would either = no or = yes and the details would follow.

*) Whatever logic required would be applied thereafter, most likely before delivery. Perhaps the MTA would be configurable to reject with a message explaining that only mail from other such servers was accepted.

If all other ideas are lost from this document, please remember this one: Beware of forcing a dependency requiring special DNS extensions. This means both DNS servers and DNS resolvers would require new software, throughout the entire Internet. While this may or may not ever happen, this dependency puts a serious crimp in the acceptance of any standard and is unnecessary. DNS is sufficient in its current form to store the necessary information.

So there you have it. My two cents worth, your valuation may differ. These ideas are open for public critique or use. If you have any comments of questions, feel free to email me at matt_AT_eisgr.com