Controlling Email Hacking and Spam, Spam, Spam, Spam.

SMTP makes spam easy.
1. Logins not required.
2. Summary of SMTP exchange from Ch. 4 notes. Note:
  1. Actual sender need not agree with either the client or From: header in the email.
  2. The recipient need to agree with the To: header, or the domain of the SMTP server.
3. Some of these things can simply be limited by server implementation.
  1. Don't just take email from anyone (see below).
  2. Don't accept email bound to a different domain.
  3. Insist that headers agree.
  4. These are often configurable features of the server software.
4. Some limitations are problematic.
  1. Would have to pre-arrange a password or key with everyone you might want to hear from.
  2. And it's not contact-to-contact, but domain-to-domain.
Mail exchangers.
1. First change is to transfer between domains only between mail exchangers.
2. This is contrary to the original intention of SMTP, but we hadn't invented spam yet.
3. This is a DNS record type. Records the server where SMTP is running.
  bennet@m-mcc-csc-01456 grades]$ dig -t MX amazon.com ; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> -t MX amazon.com . . . ;; QUESTION SECTION: ;amazon.com. IN MX ;; ANSWER SECTION: amazon.com. 900 IN MX 5 amazon-smtp.amazon.com. . . . [bennet@m-mcc-csc-01456 grades]$ dig -t MX mc.edu ; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> -t MX mc.edu . . . ;; QUESTION SECTION: ;mc.edu. IN MX ;; ANSWER SECTION: mc.edu. 86400 IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. mc.edu. 86400 IN MX 1 ASPMX.L.GOOGLE.COM. mc.edu. 86400 IN MX 10 ALT3.ASPMX.L.GOOGLE.COM. mc.edu. 86400 IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. mc.edu. 86400 IN MX 10 ALT4.ASPMX.L.GOOGLE.COM. . . .
  (Since our email is run by Google).
4. Users SMTP to their own providers MX.
5. Their MX sends to the recipient's MX.
6. And to the recipient email account from there.
Spam blacklists.
1. Limiting transfers MX to MX depends on the competence and integrity of domain operators.
  1. The operator will prevent internal customers from sending anything that looks like spam.
  2. Unless they're they're not trying.
  3. Or not trying competently: Perhaps their SMTP server is an open relay.
    1. Takes a connection from anyone.
    2. And forwards the message to another domain.
    3. Considered a server mis-configuration.
2. Several operators maintain blacklists of domains that should not be trusted.
  1. If you don't behave, your domain gets added to the blacklist.
  2. There are several. Spamhaus is the one I keep hearing about.
  3. Subscribers to the blacklist configure their SMTP servers to ignore servers on the list.
Mail Headers
1. Notice the Received: headers.
  1. Each (legit) receiving host adds one. Shows path through system.
  2. If something appears that should not be, a break in the chain can show where protections failed.
2. DKIM: DomainKeys Identified Mail
  1. Allows a domain to sign an email. Prevents handlers from modifying.
  2. Notice DKIM-Signature: header.
  3. One-letter keys.
    1. Signed by domain d.
    2. Signature includes the message and headers given in h.
    3. The signing key is fetched by DNS using the value of the s field, as svalue._domainkey.domainvalue.
      [tom@localhost outl]$ dig -t TXT k2._domainkey.nostarch.com ; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> -t TXT k2._domainkey.nostarch.com . . . ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;k2._domainkey.nostarch.com. IN TXT ;; ANSWER SECTION: k2._domainkey.nostarch.com. 300 IN CNAME dkim2.mcsv.net. dkim2.mcsv.net. 3600 IN TXT "k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx8zbrSuBn2HCE6a3H24TOo8MNqOVfKan83iOnG7cvFmpKLb048VSG49QWbmOV7beOG22EVBUU7b3IpQ3nwYptI1kMllSmjpOOpCK+GxZGHOum3cPx65G/862R39MKHsnsZyHZh+7aWyjM78qDfHmDgFGppC3OZzmUId57WawpDHhpTi0+z1UUQ0K50fkiY+qRNjkBRqjsD" "058E12U97CBk8yD5bl78uARCszn2PVWoXTljmQ0DPkOU/fTxiVG3YBEUrtscEBqYnxxlAj1APkO3dr9wQLbsuZUAM+zBJ3EKnMEbaG2fX7QEz/mTknQqg6uJVu8YO6m8yExJV0cTBgrQIDAQAB;"
    4. The b key gives the signature, bh key gives the hash of the message.
    5. The d field says who takes credit for this.
  4. Any recipient can check the signature to see that the message has not been modified.
3. SPF: Sender Policy Framework
  1. Verify that the sender is authorized by the domain.
  2. Check the sending domain for a correct TXT (no special sub-domain).
    [tom@localhost outl]$ host mail249.suw14.mcdlv.net mail249.suw14.mcdlv.net has address 198.2.183.249 mail249.suw14.mcdlv.net mail is handled by 10 mail.mail249.suw14.mcdlv.net. [tom@localhost outl]$ dig -t TXT nostarch.com ; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> -t TXT nostarch.com . . . ;; QUESTION SECTION: ;nostarch.com. IN TXT ;; ANSWER SECTION: nostarch.com. 300 IN TXT "ca3-718ae47d98cf4415928a32b034de1663" nostarch.com. 300 IN TXT "google-site-verification=JwUIUbgdQHEGaZ4T4Sgm93jfZnPV9j2Qfg_wwxo78TY" nostarch.com. 300 IN TXT "v=spf1 a ip4:94.130.36.169 include:_spf.google.com include:mailgun.org include:servers.mcsv.net ~all" . . . [tom@localhost outl]$ dig -t TXT servers.mcsv.net ; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> -t TXT servers.mcsv.net . . . ;; QUESTION SECTION: ;servers.mcsv.net. IN TXT ;; ANSWER SECTION: servers.mcsv.net. 590 IN TXT "v=spf1 ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.8.0/21 ?all" . . .
  3. The mail came from mail249.suw14.mcdlv.net, which is 198.2.183.249.
  4. Sender is nostarch.com.
  5. Looking up nostarch.com., then following include at servers.mcsv.net shows 198.2.128.0/18 valid sender.
4. DMARC: Domain-based Message Authentication, Reporting, and Conformance
  1. Sets policy to use SPF and DKIM.
  2. This policy is also stored in DNS.
    [tom@localhost outl]$ dig -t TXT _dmarc.nostarch.com ; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> -t TXT _dmarc.nostarch.com . . . ;; QUESTION SECTION: ;_dmarc.nostarch.com. IN TXT ;; ANSWER SECTION: _dmarc.nostarch.com. 300 IN TXT "v=DMARC1; p=quarantine; rua=mailto:qpat6ksm@ag.dmarcian.com; ruf=mailto:qpat6ksm@fr.dmarcian.com;" . . .
  3. Failing mail should be quarantined, and addresses for sending reports.
S/MIME
1. Allows encryption and signing of MIME data.
2. Individual sender owns a certificate much like a secure web site.
3. Secures the message between sender and recipient.