-------------------------- Message-Body-Authenticator -------------------------- Revisions: 0.01 2004-03-26 evertonsm@yahoo.com.br: Initial draft 0.02 2004-05-20 evertonsm@yahoo.com.br: DNS note, space estimative, message body munging 0.03 2004-05-26 evertonsm@yahoo.com.br: Rewording 0.04 2004-05-29 evertonsm@yahoo.com.br: Formatting, FAQ Contents: 1. Summary 2. Notes 3. Space Cost 4. Example 5. FAQ 1. Summary - MBA fights email address forgery and - makes it easier to identify spams, worms, and viruses - when domain owners publish message body authenticators in DNS, so that - SMTP receivers can distinguish legitimate mail from spam - by verifying a hashing of the message body - against the authenticator published by the envelope sender domain 2. Notes - It does not break forwarding. - It does not harm mobility. - It does not require support on intermediate mailers. - The record expiration date is used for database space management. - The message digest is required to prevent replay of a captured authenticator for other messages. - If a signed message is captured, it could be re-sent even with new headers. It's benign. MBA can only tell whether a message body was sent by a domain. - The message might be rejected after SMTP DATA. - DNS is not required to publish ID=>HASH mappings, it's used here just as example. A suitable database/directory service should be selected. - Limited kinds of message body munging are supported. 3. Space Requirements Estimative To give 10 days for a message reach all its recipients, to allow a 100 msg/s outbound mail rate from a single server, and assuming a database record consumes 100 bytes: days=10 # time to keep records in database message_rate=100 # outbound messages per second record_size=100 # in bytes echo $(($days * 86400 * $message_rate * $record_size)) 8.640.000.000 bytes This is about 9Gb of storage for a 100 msg/s outbound rate from a single server. 4. Example BEGIN bobsite.tld is publishing: _mba.bobsite.tld. IN TXT "db=dns policy=mba-header-required" _mba.bobsite.tld. IN PTR mba.bobsite.hosting.tld. Notes: a. '_mba' stands for 'message body authenticator' b. 'db=dns' means DNS is to be used as database service c. the PTR record says where the database service is hosted Bob's MUA issues the message: -- original RFC2822 message -- begin -- Subject: Party From: "Bob" To: "Alice" Hello Alice, Are you coming next week? Cheers, Bob -- original RFC2822 message -- end -- bobsite.tld MTA stores in a publicly-readable database: key: message-id = 0123456789 value: md5 = 415f3c454c31fb7dbcf4d861a66adbe5 expire: valid-until = 2004-04-30 14:50:22 GMT In this example, bobsite.tld publishes in the DNS: 0123456789.mba.bobsite.hosting.tld. IN TXT "md5=415f3c454c31fb7dbcf4d861a66adbe5" bobsite.tld MTA sends to alicehome.tld: -- sending authenticated message -- begin -- EHLO mail.bobsite.tld MAIL FROM: RCPT TO: DATA Subject: Party From: "Bob" To: "Alice" Message-Body-Authenticator: 0123456789 Hello Alice, Are you coming next week? Cheers, Bob . QUIT -- sending authenticated message -- end -- After MAIL FROM, alicehome.tld MTA extracts bobsite.tld from . Then alicehome.tld MTA finds: _mba.bobsite.tld. IN TXT "db=dns policy=mba-header-required" _mba.bobsite.tld. IN PTR mba.bobsite.hosting.tld. If alicehome.tld MTA wants to adhere to the policy published, the message would be rejected unless the header "Message-Body-Authenticator:" is available. From "db=dns", alicehome.tld MTA knows database used by the sender domain is DNS. The PTR record tells alicehome.tld MTA where the database is hosted. alicehome.tld MTA finds: 0123456789.mba.bobsite.hosting.tld. IN TXT "md5=415f3c454c31fb7dbcf4d861a66adbe5" After DATA, alicehome.tld MTA finds the message MD5 matches the published MD5, then accepts the message. On 2004-04-30 14:50:22 GMT, bobsite.tld removes from DNS: 0123456789.mba.bobsite.hosting.tld. IN TXT "md5=415f3c454c31fb7dbcf4d861a66adbe5" END 5. FAQ Q1. Isn't a 100 msg/s outbound rate insufficient for huge companies? That's a limit per sending server. One can use a larger machine or split the load among several sending servers. Q2. How can I split load from a single domain.tld into multiple sending servers? Use subdomains. For N servers: Server | Envelope Sender Domain ------------------------------- 1 | sender1.domain.tld 2 | sender2.domain.tld ... | ... N | senderN.domain.tld Q3. Won't DNS hosting choke on a 9Gb zone? 9Gb is expected to fit into RAM of one server of a huge provider. Smaller providers will need less space. Note: MBA does not need to store hashings on DNS, see Q8. Q4. How can DNS send a 9Gb zone to slaves? By using IXFR, not sending the whole zone every time. Note: MBA does not need to store hashings on DNS, see Q8. Q5. What about TTL of DNS records? ID=>hash mappings are only added to or removed from the zone. There is no record update to be affected by TTL issues. Only the SOA record is changed, but its TTL does not affect caching of ID=>hash mappings. In short, there is nothing special about TTL under MBA. Note: MBA does not need to store hashings on DNS, see Q8. Q6. What about refresh timing? Use a low refresh value or DNS Notify for master/slave synchronization. Note: MBA does not need to store hashings on DNS, see Q8. Q7. Won't the SOA serial overflow quickly at 100 updates/s? 4,294,967,296 / 100 udates/s = 42,949,672 42,949,672 / 86400s (1 day) = 497 days Note: MBA does not need to store hashings on DNS, see Q8. Q8. Are you sure current DNS software won't colapse under a 100 updates/s rate? It's possible current DNS software won't support very high update rates. However, MBA does not depend specifically on DNS for publishing ID=>hash entries. MBA requires DNS only for mapping the sender domain into the database service used. A database service suitable for high update rates can be selected. DNS is just a very practical example, maybe sufficient for light loads. Q9. Can any database service support a 100 updates/s rate? MBA does not use a complex, relational, transactional engine. MBA only needs to store cheap key=>hash mappings in a database possibly loaded entirely into RAM for maximum performance. Q10. Is MBA better than DomainKeys? There are minor differences, such as DomainKeys intending to sign whole message while MBA only signs the body. The major distinction is: DomainKeys uses PKI to sign outgoing messages in a given rate. For comparison with MBA, suppose 100 msg/s. MBA calculates hashing for outgoing messages and stores key=>hash mappings into a database consuming 9Gb for 100 msg/s. DomainKeys costs more CPU and requires PKI management. MBA costs more RAM, has a time limit for message verification (say, 10 days), and may demand a specialized database service. Q11. Why MBA does not sign message headers? Signing headers would require intermediate MTAs to re-sign every message. To protect message headers for the final user is not a MBA requirement. As MBA is a solution against spam at MTA level, it suffices to provide for MTAs a way to verify whether the body of a message was really sent by the envelope sender domain. There are better techiques at MUA level to ensure high security for messages. Q12. Are MIME parts signed? MBA proposes a single signature against the whole message body is cost-effective enough. Q13. Why MBA does not verify the From: header? Freedom to specify a From: header is important for mobility, as users benefit greatly from sending mail throught different providers while using the same email address in the From: field. Q14. Does MBA require support on intermediate mailers? No, as long the intermediate mailer does not change the message body. Q15. Won't MBA break existing intermediate mailers which change the message body? No, but the opposite is true: by changing the message body existing intermediate mailers can render MBA uneffective. MBA only supports very limited kinds of message body changes: 1. Attachment blocking by trusted MTAs (some mail virus scanners, etc): Sender verification can be performed before the virus scanning of incoming messages. If "cleaned" mail is relayed afterwards, the receiving server can skip MBA check for messages from trusted mail scanners. 2. Mailing lists attaching extra lines (adware, etc): The original sender domain is replaced by mailing list domain as return path, thus the mailing server is able to "re-sign" the message body. 3. Corporations appending legal disclaimers: The corporate mail server just adds the disclaimer before "signing" the message against the envelope sender domain. Other, arbitrary changes to message body by intermediate mailers would break MBA. Please note a intermediate mailer has options: a. Not to change the message body at all. b. Change the message body and assume responsability for it by resigning. c. Arbitrarily disrupt the message body without resigning. A mailer doing (c) would break message verification and should be fixed instead. -x-