MASS impacts upon reputation

Laws governing email policy do not always prohibit unsolicited commercial email (UCE). It is necessary that more stringent email policies are used by sending domains as demanded by recipients. Signatures, validated by keys published within DNS, allow recipients a stronger means to ascertain those domains most directly accountable for policies applied to the messages being offered. The reputation of entities submitting messages often determines acceptance, although the assessed identity is normally the IP address. Many domains use a shared outbound IP address and this may result in collateral refusals. Signed messages offer a stronger, and more specific accountable domain than that of the IP address. However, the use of domain signed messages is not a panacea. The current specification creates challenges when attempting to squelch policy breaches, see . Also, the overhead required to implement signatures, as compared to the use of an IP address for reputation assessment, requires additional defensive measures. Terminology conforms to . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The prevalence of undesirable email reaches levels where a decision to refuse a session MUST be made prior to the message exchange as a means to conserve network and system resources. The decision to refuse a session is typically based upon accrued reputations, or the access type listed by providers for the remote IP address in question. A similar level of protection is possible by basing reputations upon verified HELO/EHLO names. Verifying the HELO/EHLO name demands that clients insure requisite DNS information is reliably returned, see . Accepted practices currently forgive HELO/EHLO names that do not verify, as allowed by . To establish effective name-based reputations for defending message signature verification operations, HELO/EHLO name verification is REQUIRED. Verifiable HELO/EHLO names or domain signatures offer an alternative to the use of the IP address as a fair basis for accruing reputations. Name-based reputations may avoid collateral refusals, however, verifications of the HELO/EHLO names are then needed to provide vital network and system resource protection. A signed message permits inclusion of a new identifier that can not be falsified. The signing-domain can add an opaque-identifier together with recommendations regarding the use of this identifier in conjunction with mailbox-addresses. In addition to improving protections available to recipients, this identifier can also be used to abate abusive message replays. The lookup required to detect a revocation of the opaque-identifier can be mitigated by the HELO/EHLO name being within the signing-domain, or by a valid hash of the RCPT TO parameter. Resource protection mechanisms SHOULD be based upon a single DNS lookup to verify the authorization and authentication of the sending SMTP client. When, by convention, the HELO/EHLO name is normally within the signing-domain, then a few other efficiencies are made possible. It becomes possible to skip reputation checks for the signing-domain after a reputation check of a HELO/EHLO name that is within the signing-domain. As mentioned, when the HELO/EHLO name is within the signing-domain, checking the status of a specific opaque-identifier should not be needed. Had the account been revoked, it SHOULD be impossible for these messages to be signed with a revoked opaque-identifier. Systems suffering a security breach have become a significant vehicle for sending abusive email. Millions of compromised systems may act as SMTP clients or utilize automated access to the provider's SMTP servers. Any mechanism enforcing email policy SHOULD verify the source domain or use the remote IP address as a basis for reputation accrual. As a result of domain verification, those accountable for maintaining security will have been determined when abuse is discovered. Authentication ensures the validity of these identifiers used as a basis for network protection. Assumptions regarding sources of abusive email or a presumption of security may injure innocent parties and damage the integrity of email delivery. With tens of millions of good and bad evolving email domains, it is less effective to abate abuse or maintain security where each recipient contemporaneously establishes acceptance criteria. White-listing large domains, demonstrating good governance controlling abuse, will categorize a major portion of the messages being assessed. While this reduces the number of messages needing evaluation, the categorization of remaining sources still represents a sizable expense. Often a community of administrators pool efforts and create shared lists that offer histories for an extensive number of email sources.

The pooling of efforts is often accomplished through reputation services as a means to establish policy within a community. Those with even a brief history of not adhering to these policies are thereby excluded from the community. Real-time black-hole lists have become a commonly used mechanism to publish IP address related reputations, where having no record returned indicates a good reputation. As an example, a community wishing to enforce an Opt-In requirement for bulk email often employs an email reputation service to establish such community-wide policy. Reputation service subscription fees, if any, are typically paid by the recipient. With such a service, those sending abusive levels of unrequested email to anyone within the community may find subsequent sessions refused with an error response. This response often indicates which reputation service reported their server as not having a good reputation with respect to specific polices. The extent of email abuse has made reputation services an integral component of network resource protection. Some bulk email distributors also utilize a vouching or accreditation service which attests their compliance to specific policies. To benefit from the accreditation, the recipient must rely upon the service, but fees for this type of service are usually paid by the sender. Mechanisms for accreditation services are often similar to real-time black-hole lists, except the record may also assert favorable ratings. Sender based fee structures for accreditation may provide greater latitude for senders, which may then dissuade some domain administrators from utilizing these services. Some providers may utilize accreditation services together with their own white-listing of bulk email distributors, as an adjunct to real-time black-hole listings. White-listing by IP address is difficult to maintain. Accreditation services assist with this white-listing effort for bulk distributors where their volumes often mislead filtering algorithms that categorize the distributors as abusers.

Filter programs often place messages into several categories. Placement of messages into suspense pending review, often hides the filter's actions, and inhibits challenges by senders. Often, when filtering provides multiple categories, a portion of these categories are marked suspicious and left to the recipient to make a final determination. The lack of feedback prevents assurance of email delivery. There MUST be an ability to challenge a categorization to ensure the integrity of email delivery. A filter program's "Junk" folder contains email that has not been properly excluded by policy enforcement, but is without a strong basis for rejection. Even when a filtered message is rejected which provides feedback, it may be due to a phrase contained within the message. A doctor's reply to a patient may be steadfastly rejected regardless of which provider is used. Unfortunately, many of these filter programs have evolved to also silently discard messages, once some level of heuristics has been achieved. This mode removes all traces of the message for both the sender and the recipient. As a result of a breakdown in policy enforcement and the resulting reliance upon filters which silently discard as well as place messages into the often ignored "Junk" folder, the integrity of email delivery has been reduced.

As a basic principle, abuse prevention REQUIRES source verification and accrual of reputation. For effective abuse prevention, sources SHOULD resolve to the sending domain to establish an appropriate hierarchy of accountability. However, adding recipient overhead for discovering mailbox-domain authorizations increases the risk that the recipient's resources will be exhausted. Furthermore, after the recipient expends these efforts to determine a mailbox-domain's authorizations, the resulting authorization could be inappropriately considered equivalent to having verified the source domain for purposes of accruing reputations. There have been several schemes proposing accrual of mailbox-domain reputations, often using recipient feedback techniques. This accrual erroneously presumes that the mailbox-domain has been authenticated, rather than just having authorized the system handling the message. When recipients consider path or signing-domain based authorizations as being equivalent to verifying the source domain, this creates an unfair basis for accruing reputations. The mailbox-domain owner often has no administrative oversight to assure the protection of the mailbox-domain owner's reputation. Instead of authorization records preventing harm, these authorization records may actually cause an otherwise unevaluated mailbox-domain to create a bad reputation for the owner, when a mailbox-domain is still falsified by abusive messages. Assuming the recipient checks for mailbox-domain authorizations, the anticipated benefit of preventing misuse then depends upon the mailbox-domain owner accepting additional conditions. The mailbox-domain owner MUST fully depend upon a provider ensuring the exclusivity of the outbound mailbox-domain. Also, the mailbox-domain owner MUST accept the loss of emails in some cases. This loss occurs when the authorization mechanisms are limited to using commonly visible or determinate mailbox-domains. Present conventions may establish the sending entity with a typically invisible or perhaps indeterminate mailbox-domain. Granting authorization exceptions to accommodate differing conventions offers opportunities for exploits. Not granting exceptions increases the support needed for non-conforming mechanisms that result in email loss. Authorization schemes devise mailbox-domain/signing-domain or mailbox-domain/path relationships. Establishing these relationships entails significant administrative effort as well as protocol overhead. Exceptions granted may potentially mislead recipients, by offering false assurances when the mailbox-domain authorization mechanism indicates success. Proponents of mailbox-domain authorization mechanisms ignore the uncertainty of the mailbox-domain's visibility, selection, and origin. Recipients will still confront abuse from mailbox-domains providing authorization. Reputations based upon mailbox-domains may create unwarranted email delivery failures. The inappropriate application of reputation occurs when recipients use authorization as a basis to hold potentially falsified mailbox-domains accountable, as their means to abate the abuse. Currently abusers control millions of compromised systems, and can take advantage of weak mailbox-domain authorizations. Abusers may exploit published records that register permitted mailbox-domain paths or signing-domains, to usurp previously good reputations. When abuse occurs that still falsifies the mailbox-domain, the mailbox-domain owner's tainted reputation may subsequently cause this domain's emails to be blocked. What is worse, redemption of a mailbox-domain owner's reputation may not be practical due to the typical mailbox-domain multi-level authorization scheme that follows a filtering paradigm. The mailbox-domain may not receive notification their emails are being placed into "Junk" folders. There are many weaknesses associated with path or signing-domain based authorizations where the mailbox-domain can still be falsified. Abusers may take advantage of a mailbox-domain owner's desire to ensure emails are delivered by allowing exceptions. Abusers may also take advantage of an email provider's failure to check mailbox-domain authorizations, or failure to license mailbox-domain selection algorithms. Nevertheless, with these flawed schemes, the mailbox-domain within the selected header is held accountable for having sent the message, when this accountability is only supported by authorization records. Some call this unfair assumption that holds the mailbox-domain accountable, "Sender Authentication." Calling the authorization derived from a mailbox-domain "Sender Authentication" would be similar to making a declaration that the postal service is authorized to deliver letters for John Doe, where recipients then claim any letter received from the postal service and bearing John Doe's name is authentically or genuinely from John Doe. Of course, that would be a false assumption, and path or signing-domain based authorizations are no different. It is normal for mailbox-domains to employ common service providers. It is also normal for service providers not to adopt specific checks requiring extensive support. Mailbox-domain authorizations do not provide a safe or practical solution for mailbox-domain falsification.

How will abusers take advantage of normal desires and the false assumptions surrounding mailbox-domain authorization? While strictly limiting authorization to just an email provider's servers could reduce risks of a mailbox-domain being falsified, this could also cause some messages to be lost as a result. The loss could occur when recipient's providers select mailbox-domains using an incompatible algorithm. Recipients could also be forwarding messages which may result in email losses. For example, with messages first sent to an alma mater's domain, forwarding may make messages appear to be unauthorized. Messages may also be lost when sent through some list-servers, or through servers running older versions of email applications. Why quibble over who is responsible for implementing changes that often takes many years? For the loss of messages due to an incompatible authorization scheme, the remedy invariably suggested would be to leave mailbox-domain authorization open-ended. Open-ended authorization simply declares a lower level of authorization rather than authorization failure. The multiple levels of authorization is intended to alert recipients to increase scrutiny given messages with lower levels. However, this lower level of authorization can not ensure the mailbox-domain owner's reputation remains protected. For example, abusers can take advantage of automatic image fetching to compile valuable lists of active email accounts by using encoded image links. These abusers don't care which folder or level of authorization they obtain. They don't care that recipients fail to respond, and they would be thrilled to see recipients make the effort to unsubscribe. The mailbox-domain owner's next concern is whether the recipient of a message clicks the "spam" button when messages have falsified their mailbox-domain. Conventions remain uncertain for selecting the header being checked for authorization. Email providers rely on open-source applications and are understandably reluctant to enter into licensing terms that are hostile to the open-source methods of software distribution. It is also understandable some providers will only consider using non-proprietary algorithms for basing their assumptions of who originated the message. These providers can not inspect some headers without violating claims of intellectual property, when there are also proprietary header selection algorithms. Each selection approach creates compatibility issues requiring differing mitigations. Some providers will utilize a proprietary algorithm and enforce their view by incorporating reputation extensions into MUA plug-ins that take an already unfair basis for reputation to a new level of being unfair. With either path or signing-domain authorization records being very public, a mailbox-domain owner's reputation will be exposed to any possible weakness. Publishing open-ended authorization records may even act as an invitation for this abuse. Furthermore, a provider that does not ensure message headers are not in conflict with other customers across all possible interpretations, may risk the mailbox-domain owner's reputation, especially when this provider's limitation becomes known. With phishing techniques becoming seemingly epidemic, mailbox-domain authorization is often touted as a remedy. With respect to phishing, these authorization schemes may bypass the From header as the basis for acceptance, even though this is the header typically assumed as verified by recipients. Some MUAs have made this problem worse by displaying user friendly names, known as the "pretty" names, rather than the actual mailbox address. Phishing ploys often use disposable domain names with obfuscated links, which could also provide a variety of mailbox-domain authorizations as a means to obtain false assurances. Mailbox-domain authorization records can covertly authorize the entire Internet to enable a compromised system anywhere in the world. Mailbox-domain authorization, as a phishing deterrent, presumes wide adoption of an algorithm by mail clients and providers. However, assurances offered by mailbox-domain authorization "aware" applications are dangerous, due to the possible use of hidden headers, and reliance upon uncertain interim authorization checks. This may actually place consumers in greater peril, when trusting false assurances. Mailbox-domain authorization requires that mailbox-domain owners trust their email providers, although many providers do not authenticate their own customers, and do not care what mailbox-domain is used. Such providers will be exposing the mailbox-domain owners who publish mailbox-domain authorization records to substantial risks. Mailbox-domain authorization does not identify these providers either, so there is no accountability that directly assures a provider's diligence. Mailbox-domain authorization itself may weaken the integrity of the DNS. One draft risking the integrity of DNS only offers the advice that providers use "properly paranoid DNS resolvers." Path based authorization records catalog all outbound MTAs of a domain and may demand a minimum of more than one hundred DNS lookups, while also ignoring UDP exponential back-off. Signed-domain authorization records require walking up the DNS label tree from five levels below the root. This occurs for mailbox-domains that have not made an indication that a mailbox-domain authorization scheme is supported. This will increase DNS traffic and likely obligate root name servers to issue negative authorization records to mitigate the authorization query overhead. Mailbox-domain authorization records can not offer network resource protection, but actually put these resources at risk. Publishing mailbox-domain authorization depends upon providers inspecting all possible interpretations of the message headers and envelope parameters. To do this, providers may either limit their customer's choice of mailbox-domains, or isolate their customers outbound servers or IP address. The mailbox-domain owner suffers harm when the provider is negligent at controlling access and establishing the needed constraints, since the provider remains anonymous. Furthermore, the mailbox-domain owner will be left in the dark as to the cause of their dilemma.

The opaque-identifier is a mechanism being suggested by this document. The term 'opaque' means that only the domain creating the identifier understands the relationships described. There could be two modes used for creating the content of the opaque-identifier. One mode would be persistent with the account used to access the signing-domain, and the other could be sequential for cases where an account is not involved. A prefix could be added to the sequential opaque-identifier to prevent collisions with the identifiers used for accounts. A sequential opaque-identifier may be appropriate for distributing bulk mailings. To identify the abusers that may attempt to stage replay attacks, having a unique identifier sent to each recipient could be helpful. These replay attacks could be done using the unchanged content of the message, but sending to recipients that would consider the information to be unsolicited. The reason for such a replay attack may be to damage the reputation of the signing-domain. If an identifier were added to an unsigned message, this would invite forgery and therefore offer little value. A standardized opaque-identifier, included within the validated content of a signed message, would offer significant value. It would be an opaque-identifier added to the signature header that is valid as a domain name label. A persistent opaque-identifier would be most useful when derived from the access server that authenticates the account being used. The opaque-identifier would greatly aid the correlation of abuse and prove most useful for locating compromised systems. This approach could be effective against systems compromised by Trojan programs, stolen passwords, and cracked wireless access points, among many other nefarious methods. Abuse reports that catalog signed messages and that are correlated with the opaque-identifier, would provide incontrovertible evidence of where the source of a problem exists. The publishing of the revocation record for the opaque-identifier would also provide feedback that actions were taken to rectify a policy breach. In odd cases, where the HELO/EHLO name is not contained within the signing-domain and where the RCPT TO hash is not valid, a single lookup of the opaque-identifier returning no record would be an indication that this particular opaque-identifier is still authorized by the signing-domain. This mechanism would be most valuable in those cases where the message may have been forwarded, such as at the typical alma mater, or where a mailing list opts to also forward signed messages unaltered. If there is a problem, the signature would offer the name of the most capable domain to remedy abuse. People can still safely use their forwarding email accounts given to them by their school or society. Mailing lists would be given a strong identifier upon which to grant the replication of messages. The best part, complaints would also likely be directed to those most able to curtail future episodes of bad behavior, i.e. the provider of the abusive account! The construction of this revocation record mechanism could take the form of a single A record lookup. The opaque-identifier would be composed of 1 to 63 characters and select a record in this fashion: Within the signature header, a parameter u=<opaque-identifier> would indicate the use of a opaque-identifier. <opaque-identifier> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= %x41-5A / %x61-7A <digit> ::= %x30-39 <opaque-identifier>._rl.<signing-domain> IN A 127.0.0.2 When the signing-domain has not revoked authorization for this identifier, no record would be returned and the remote DNS cache would retain the absence of this record for a brief period of time, see . For the majority of cases, where messages are obtained directly from the signing-domain, an exception granted by the HELO/EHLO being within the signing-domain allows this revocation check to be skipped. A revocation check would be made for the odd cases where the HELO/EHLO is within a different domain and the RCPT TO hash is not valid. This check would be performing nearly an identical lookup now ubiquitously done to investigate the status of the SMTP client's IP address against a real-time black-hole list. Those addresses or identifiers that warrant refusal are granted a long lived address record to ensure their immediate refusal and limit DNS traffic resulting from abusive sources. Otherwise, not offering a record allows for the prompt cessation of an opaque-identifier's authorization when the situation regarding a particular identifier changes. The Time-To-Live for negative DNS caching may be determined by the recipient, or represent the lesser of the SOA TTL or the SOA MINIMUM field, depending upon the recipient's implementation.

There are at least two techniques that can be used to detect when the message's path has been altered. Verifying either check can mitigate a need to do a revocation check on a opaque-identifier. One check would be verifying that the hash for the RCPT TO parameter is valid. The other would be verifying the HELO/EHLO name and confirming that it is within the signing-domain. The purpose of the RCPT TO hash would be to provide an indication of when to check for the opaque-identifier revocation, as an alternative to the HELO/EHLO being within the signing-domain. There should be practical methods used on the RCPT TO line which obfuscates the hashed information. Perhaps, randomly modifying the case of letters within the mailbox-domain and modifying the amount of white space could act as a type of salt. The goal is to mitigate extra DNS lookups, albeit small in this case. The RCPT TO hash option would also instill a practice that provides better tracking abilities when problems occur, without depending upon other steps being taken. The RCPT TO could use a white-space sensitive canonicalization that combines the RCPT TO parameters into a single SHA-1 hash. This hash would be added to the signature using base64 encoding as a "r=" parameter, for example. List servers that pass messages unaltered, or recipients that employ forwarding accounts could be fairly common scenarios where a revocation check would be required. The reaction deterring the replay attack must be rapid, but does not require all abusive messages be stopped. This rapid response will expose participating SMTP clients and reduce the profits of the abusive behavior. The loss of the profits and the exposure should act as a deterrent.

Binding identifiers allows a recipient to recognize a prior correspondent without the use of complex and problematic mailbox-domain authorizations. Mailbox-domain authorization problems may create support issues that could significantly thwart deployment. The MUA is able to associate visual items from prior correspondents and obtain a higher granularity and history of signed message sources without using any DNS lookups. The identification of the message source is contained completely within the message itself. When assuming legacy MUAs, scant protections are possible by the MTA even using many DNS lookups. Due to limitations of ensuring visibility of checked domains, the MTA approach provides an alarmingly low level of mailbox-address protections. There is also a potential for an undesired exposure of mailbox-addresses in the 'i=' parameter. Mailbox-domain authorizations depend upon the signing-domain verifying the validity of the local-part of the mailbox-address for the recipient to detect intra-domain spoofing. A suggested opportunistic approach could be used to detect when a previous correspondent appears to be from a different point of origin. The approach would rely upon the collected relationships discovered within signed messages. The signed message may even advise what information should be compared against the mailbox-address and perhaps even the pretty-name. While in most cases the collected relationships (bindings) would be made at the behest of the recipient and require their approval, some relationships could be established automatically. To reduce user interaction needed to establish bindings, there would be three modes expressed by a scope-width parameter included within the signature header. A value of "w=n" would indicate a narrow binding recommendation, and a value of "w=b" would indicate a broad binding recommendation. A Narrow binding would include mailbox-address/signing-domain/opaque-identifier, whereas the Broad binding would include just the mailbox-domain/signing-domain. No "w=" parameter would indicate that no bindings are recommended. A provision should be added to indicate when a key had been delegated. The message signed with a delegated key should not be trusted to make recommendations with respect to the scope of a binding. There should be a parameter added to the delegated key where "d=n" parameter indicates that the key has been delegated and the recommending binding for delegated keys is narrow. In the case of a delegated key, the opaque-identifier and the key selector MUST match. The suggested binding are recommendations for the type of pseudo-certificate created to uniquely identify a correspondent for future reference. One could argue that 'ssh' is one of the most widely used cryptographic protocols, which often relies upon "opportunistic cryptography" by saving self-signed certificates. This document is suggesting this 'ssh' model could also work for . In the case where the "w=b" and the mailbox-domain and signing-domain match, the MUA, perhaps even the MTA, could cache the pseudo-certificates for the correspondents. When the mailbox/signing domains are the same, and when the message advises that only the mailbox/signing domains are essential to identify the originator of a message, then it should be safe to capture this relationship automatically. With the relationship information captured (cached), the MTA or MUA would be able to detect when a message violated these expected relationships. In the case of a particular domain that recommends only the signing/mailbox domains be bound, then after the initial contact by anyone within that domain, comparing against the captured signing/mailbox domains could indicate when the source of a message appears suspicious. If a subsequent message appeared suspicious coming from a list server, then the recipient could merge the list server domain within the associated relationship. This approach would make it more advantageous for list servers not to damage initial signatures. A recipient could recognize the originator of a message even when there are no assurances being made regarding the mailbox-address, by using the opaque-identifier that tracks accounts added by the signing-domain. This opaque-identifier would become a part of the captured relationship once approved by the recipient. This approach means that providers that do not constrain their customer's use of a mailbox-address still offers significant value for their customers. Other out-of-band techniques could be used to strengthen the identity of the individual without involving the email provider.

Reduce reliance upon filtering that either discards or "junks" messages. A growing loss of integrity in email delivery is eroding email's value as a method for conducting transactions. This loss of integrity is largely caused by filtering programs that process messages based upon weak identifiers. A filter program's use of heuristics with weak identifiers demands growing resources and may cost senders the loss of their messages, even to the point where their mailbox-domain becomes unusable, with no clear recourse for correcting errant behaviors. Remove advantages gained by spoofing the bounce-addresses by not returning the original content of the bounced message within the Delivery Status Notification (DSN). This should curtail the exploitation of an MTA, that performs checks after accepting the message with a spoofed bounce-address intended to be bounced. Reduce the exposure to the DSN from messages with spoofed bounce-addresses by implementing a time constrained cryptographic signature within the local-part of the bounce-address for all messages sent, as described in . Improve the integrity of email by using reputations based only upon authenticated identities, where messages are either fully accepted or refused. In email, there are only three identities that can be authenticated: the IP address of the sending MTA, a somewhat stronger HELO/EHLO, and a much stronger message signature. Authentication of identities provides a means to fairly assess the sources for possible abuse. The IP address and HELO/EHLO domain represent the administrator for the last step in the message's delivery. A message signature represents the domain administrator granting initial access. Protect the signature validation process by utilizing an authenticated HELO/EHLO name to establish a reputation for the session prior to an exchange of messages and prior to the validation of signatures, see . The authentication and authorization of the HELO/EHLO name can be validated within a single DNS lookup. The DNS infrastructure that provides the signature keys also requires better protections. Do not expect the DNS server to handle active scripts that demand extensive lookups. Ultimately, the deployment of for DNSSEC is required. Limit exposure to the replay of signed messages. Although a message signature provides the strongest authentication and offers the recipient the best protections from spoofing or phishing, it could be abusively repeated beyond the signing domain's control. As a defensive measure, when needed, a message signature should also permit inclusion of an opaque-identifier. The opaque-identifier would both ease correlation of abuse, and enable a means to squelch "replay attacks." For example, when the key or signature remains valid for one week, publishing a revocation record within minutes of an abuse report would reduce replay exposure by a factor of 2000 to 1, and would clearly unveil replay sources to all recipients. While message signatures offer little network protection, they indicate the administrator most able to prevent future breaches of policy. Message signatures also truly afford protections from the initial sources being spoofed. Assert email policy for the domain, see . Currently this DNS record allows a domain to assert that all of their SMTP clients will be authorized and authenticated using . A signed message allows safe assessment of the message source by making no presumptions of intervening security. At an administrative border, policy assertions, as well as the domains validated, may need to be communicated to another MTA within the administrative domain, where signature validation may occur. This document recommends a possible structure for transferring this information.

The relative simplicity of the DKIM proposal represents an essential element needed to sustain the performance demanded by the email infrastructure. While policy enforcement necessitates cancellation of access rights, using signatures also necessitates a need to revoke user authorization implied by a valid signature. This is not equivalent to a certificate revocation as defined for PKI in . A proposed method in this document achieves the revocation mechanism, and only requires a simple exchange for infrequent cases. In fact, certificates would be unsuitable for fulfilling this need, as certificates per-user would represent an undue burden. For large providers, two certificates per user would be needed to accommodate the mail transit time during a certificate change-over. A domain with 20 million users would then require close to 7 GB of data published on-line. Even when subsequent certificates are phased-out in stages, any extended period for such staging would increase the size of certificate revocation lists (CRL) which, to be effective against abuse, would require frequent polling. Recipients would then need to cache this voluminous information for all users exchanging messages. As an alternative, by adding a persistent identifier within the message, the amount of information exchanged would represent 6 orders of magnitude reduction, while still providing the same capabilities. For the smaller providers, not incurring the added expense of acquiring certificates helps reduce barriers to the deployment of message signatures. A certificate authority typically ensures the identity of the certificate holder, but is less concerned about adherence to various email policies. There would still be a need to verify the reputation of this identity against desired policies, as a basis for accepting their messages. While using DNS to distribute keys reduces what could be a substantial expense, this relatively simple mechanism is not without risk.

RSA keys are used by the proposal and, for this review, are assumed to follow the outline in . The processing to verify a signature is roughly dependent upon the square of the key size. The overhead associated with certificate or key handling is ameliorated through retention within a cache for extended periods. In the summer of 1995, RSA laboratories recommended a minimum key size of 768 bits for user data, 1024 bit keys for enterprise keys, and 2048 bits for root keys. Since that time, with Moore's law providing a doubling of performance every 2.5 years, today's system's performance is approximately 16 times faster. At an RSA challenge in August 1999, a 512-bit value was factored using 35.7 CPU-years. Other concerns regarding the time to factor the key involve the advancement of programmable or custom logic. These hardware advances further increases the performance of factoring by thousands of times more, especially for smaller keys where the needed memory size remains practical. Factoring memory requirements: Key Size Time Factor Sieve Matrix 512 1.7 x 10^19 3MB 128MB 2GB 768 1.1 x 10^23 240MB 10GB 160GB 1024 1.3 x 10^26 7.5GB 256GB 10TB There are speculative estimates that with as little as $5,000 worth of specialized hardware, a 768-bit key could be determined within 95 days, see . Extrapolating from this figure, it may take $200,000 to do this within 3 days. With the growing plunder achieved by criminal activity that sends email to entice victims, this expense may not be an adequate deterrent. Today's recommended minimum key size of 1024-bits seems well justified. It will change to 2048-bits by the year 2015, based on a tentative schedule provided by the NIST, see . provides details relevant to assessing key strength. A very rough estimate of processing overhead for signatures assumes that memory caching and higher processor performance provide about an 8 times improvement over memory bus rates. The following formula was used to estimate performance: (80,000 + 32 (key-bit-size^2) + 448(message-byte-size)) / bytes/second memory-speed Note: Once actual results are evaluated, constants within this formula will need adjustment and should also vary between different architectures. At 768-bit keys and a CPU using 2100 MB/second memory, the overhead for an 8 KB message estimates to be around 10.7 milliseconds. The same parameters with a 1024-bit key would result in 17.8 milliseconds. This suggests that when changing from 768-bit to 1024-bit keys, the resulting overhead should increase by a factor of about 1.6. Such a CPU using 2100 MB/second memory dedicated to performing this operation, could then handle daily about 4.8 million messages that average 8 KB in size. Message Size Signature Time Message/min 1,000 16 ms 3,700 5000 17 ms 3,500 10,000 18 ms 3,300 50,000 27 ms 2,300 100,000 37 ms 1,600 This table is for a CPU using 2100 MB/second memory validating 1024-bit keys. This shows that beyond 100,000 byte messages, the much faster hash function becomes predominately the limiting factor.

To provide the conveyance of information obtained at the receiving administrative border, a new header is introduced. This header documents the methods and results of message validations performed. It is added at the top of the message solely by the Internet facing border MTA. Any previous Border-Validation header introduced at the Internet facing MTA should be stripped and may be viewed as an attempt to forge this information and cause the message to be rejected. This header has the following format: header := "Border-Validation" ":" domain"["address-literal"]" 1*LWSP *(";" method "=" result) domain := Domain as defined in address-literal := Address literal as defined in method := "CSV" | "DKIM" | "RDNS" | "A-RR" result := authen "/" author "/" assert "/" time "/" hash authen := "VALID" | "INVALID" | "UNKNOWN" | "ERROR" author := "VERIFIED" | "MISSING" | "UNKNOWN" | "ERROR" assert := hexadecimal presentation of the CSV-CSA port field. time := time value defined by recipient hash := defined by recipient to cover domain, address-literal, method, and result. LWSP := 0x20 / 0x09 "CSV" refers to the procedures defined in . "DKIM" refers to the procedures defined in . "RDNS" refers to the validation of the HELO by using a reverse DNS lookup of the remote client IP address and verifying the HELO name, which will provide "UNKNOWN" authorization. "A-RR" refers to using a lookup of an address record for the HELO name, which will also provide "UNKNOWN" authorization. Authen is for authentication and author is for authorization. A "VALID" authentication indicates the domain has been confirmed by the method indicated. "INVALID" indicates the method attempting authentication has failed. A message that fails authentication should be refused. An authentication returning "UNKNOWN" indicates the client does not conform to a standard which assures authentication. Authentication returning "ERROR" indicates a system related failure has prevented a determination. A "VERIFIED" authorization indicates the client supports . A "MISSING" authorization indicates the client supports or but has determined the client or message is not authorized. Normally this should cause the message to be refused. "UNKNOWN" authorization indicates the client does not support . Authorization returning "ERROR" indicates a system related failure has prevented a determination.

provides a means to make domain-wide assertions. Currently, only the use of CSV itself is defined. The Port field of the CSV-CSA record defined in can be extended to make signature related assertions. Bit Value Meaning 1 Explicit: All authorized names have specific CSV-CSA records. 2 All Messages Signed using DKIM. 4 HELO/EHLO within signing-domain. - Other bit values are reserved for expansion and must be set to zero. This range of values should be ignored by the recipient when their function is unknown. Asserting that "all messages signed using DKIM" allows other domain signatures to be used, but makes an assurance that all messages sent by the MTA will be signed. Asserting all "HELO/EHLO within signing-domain" makes an assurance all messages sent by this MTA can be identified by a parent domain signature.

There are no IANA considerations in this draft.

Signatures hold the promise of enabling safe and strong methods for recipients to assert their own policy requirements. Signatures should be used in conjunction with HELO/EHLO authentication and a opaque-identifier to provide a low risk, low impact method to improve the integrity of email messages. Even if consensus can be reached regarding which mailbox-domain is to be constrained by a path or signing-domain based authorization list, and this mailbox-domain were universally checked, this still assumes all systems are secure, for any resulting conclusion to be valid. There can be no open system that abates abuse, without the application of reputation or accreditation. Applying reputations against a mailbox-domain puts consumers in extreme jeopardy and the email delivery system at risk. To ensure consumer safety and the integrity of email delivery, reputations MUST only be based upon authenticated entities. The stronger the authentication, the safer the mechanism is for providers and consumers alike. Signatures can be implemented unilaterally and are not premised upon adoption of new universally applied checks. The benefit of complaints being directed to the appropriate administrator justify the modest costs for signatures. Signed messages add value for customers, especially when signatures become a minimum requirement for various services. Rather than being a method that targets the current behavior of abusers, signatures offer a real means to ensure the source of a message. The current proposal lacks a much needed means to eliminate a replay and DoS attack, but this can be addressed through the inclusion of the opaque-identifier and conventions establishing the verification of the HELO/EHLO. The signature's key sizes should be reconsidered, where support for 512-bit keys should not be required. The number of key selectors, when both DNS traffic and protective strategies are considered, don't lend themselves to be used on a per-user basis, especially for larger domains. Should such use become common, recipient DNS caches could be overwhelmed with key information. In conclusion, signed messages provide excellent protections for both the MTA administrator and the mailbox-domain owner alike. In addition, with a persistent identifier incorporated, signatures offer a means to rapidly abate abuse from compromised sources, even within large domains. Using a valid signature, rather than an unauthenticated mailbox-domain, for assessing reputation will not invite more egregious behavioral changes in criminal activity, nor raise legal disputes over who should have been held accountable for abuse.

Earl Hood has been making several good suggestions, where I incorporated his concept of including a copy of the RCPT TO as a part of the message. This was changed to being a hash of the RCPT TO with the intent of discovering whether the path of the message had changed. In the same fashion as adding the RCPT TO hash, Earl also suggested adding a body hash to be able to isolate body content alteration from header alterations.