Spam reduction using messageid.

A rudimentary suggestion of a protocol is introduced. Reference is made to RFC2392.

Spam has grown from being: An interesting side-effect of new technology. A sometimes useful marketing tool. An overload of inbox-time. An overload of disk space. An overload of bandwidth. A dangerous affliction to useful technology. This document suggests a technique for reducing spam dispersion. Some estimates put spam traffic at astonishing levels. Reports are available which speak in terms of 50% of email traffic. Clearly there is much to be saved with reducing this traffic.

A fundamental question in confirming the origins of an object is to ask if it was sent by the sender. Current smtp sessions are in the main, send and move on the next task. There are of course, many tests made by the receiving agent as to the validity of the email. Though in search of a basic confirmation exchange, it could be found that a mechanism is already half in place. In the form of the MessageID header of every email. If the sending agent stores the MessageID data for a length of time, then the receiving agent was to query the originating agent on this field, confirmation of the send could be confirmed or denied.

It may have been impossible for earlier agent implementations to do this due to the storage and processing requirements percieved. The cost of these is now greatly reduced. Calculations would show it to be cheaper than the cost of current spam volumes. Additionally, product such as SQLite have not been available until recently.

The MessageID is a header field generated by a sending smtp server. Although Message-ID generation does need to be globally unique, there is an Internet Draft which suggests this possibility: draft-ietf-usefor-message-id-01.txt It is generally generated to be locally unique. It usually uses the FQDN as a suffix, though as there has been no reason to use the uniqueness across domains, non-FQDN use has not been questioned.

To ensure a reasonable path to implementation, conforming agents could be given a bypass filter. This would reduce load on filters, reducing load on servers.

Of significant annoyance to emailer.1 occurs when bounces are received from emailer.2 who have spam which appears to originate from emailer.1's domain, when in fact they are from a spamming bot-net or similar. Reduction in spam, registered addresses. Reduction of virus payloaded spam.

Spammers will require a registered domain with a DYS enabled server. Reverse tracking is therefore possible. Confirmation the spam was sent is implied. In countries where spam is illegal, this may be useful as evidence. In other countries, the sending smtp server is visible and block able.

Scenario 1: Spammer creates botnet which targets a number of domains. The domain's issue DYS's towards (unconfirmed) originating server/s (DYS.UOS). The UOS's reply with many DYS 'UNKNOWN'. UOS's are inundated with DYS requests with possible adverse effects. This requires a map of domains to smtp servers.This can be gained from MX records. Response to this attack could be a focussed blacklist. Scenario 2: Spammer creates botnet which directly issues bogus DYS requests. Mitigation: Check of reverse IP MX record would indicate a firewall rule is required Scenario 3: Spammer uses registered MX server to send spam. A firewall trigger could block traffic after a number of requests.

This is a function of co-operating smtp agents. If all agents used this protocol, then 'spam' as we know it would be greatly reduced.

The sending agent has options on storage period of sent ID's. Subsequent handling of receipts could flag or delete the sent.ID. The sending agent could flag the sent.ID with the time of receipt.

There is an obvious need to track back through the 'Received:' path entries to the public facing smtp server issueing the email. To shorten the seaching operation it is suggested that a prefix be added to the entry of the public facing server, such as 'dys.publicfacing.server.com'. This facilitates the need of backtracking, firewall requirements, redirection and any need to seperate the dys function. This also facilitates the testing options leading to integration.

The dys protocol is suggested to be an extension of the SMTP protocol. Firstly, the ability to recognise any 'not available' signal is suggested. The server is reached via the prefix 'dys', though it is not configured as such: (smtp exhange).... 'DYS' sent , reply= '502 Error, command not implemented' = backoff to regular spam checks (smtp exhange).... 'DYS' sent , reply= '502 Error, server busy' = backoff for configured period (smtp exhange).... 'DYS' sent , reply= '502 Redirect, an.otherserver.com' = backoff and retry at an.otherserver.com The server is reached and provides dys.(ESMTP probe). (smtp exhange).... 'DYS' sent , reply= '250-DYS' (in exchange). The server is reached and queried in one operation. (smtp exhange).... 'DYS 40F655CA30A781488E7BADFECFDA05690769F40B@mail.acorp.com' The 'dys server' makes a lookup request and replies. Answer: NRF = 'No Record Found'. Answer: DSRR = 'Did Send Receipt Received'. (Did Send, but already marked as received). Answer: RF = 'Record Found'.

See section entitled: Denial of service risk.

This document has no actions for IANA.