Posts

Showing posts with the label Email Security

PGP and GPG: The Web of Trust and Why Email Encryption Stayed Niche

PGP is a hybrid cryptosystem for encrypting and signing files and messages, and GPG is its widely used free implementation. Technically it has aged well; as an email encryption scheme it never achieved broad adoption, and the reasons are instructive about usability as a security property. How the hybrid scheme works PGP does not encrypt a message with the recipient's public key directly — asymmetric operations are far too slow for bulk data. Instead it generates a random symmetric session key, encrypts the message with that, then encrypts the session key with each recipient's public key and attaches the results. Each recipient uses their private key to recover the session key, and the session key to read the message. This is the same pattern TLS uses and the standard arrangement described under asymmetric encryption : asymmetric for key establishment, symmetric for the data. It is also why adding a recipient is cheap — one more encrypted copy of a small key rather than ...

SPF, DKIM and DMARC: Configuring Email Authentication Properly

Three DNS records govern whether a receiving mail server believes a message came from your domain. They do different things, they are frequently deployed partially, and a partial deployment provides much less protection than the presence of the records suggests. SPF A TXT record listing which servers may send mail for your domain. A receiver checks the connecting server's address against it and gets a pass, fail or softfail. Two limitations matter. It authorises servers , not messages, so anyone able to send through an authorised server passes — which includes other customers of a shared mail platform if the record is written too broadly. And it checks the envelope sender, not the address the recipient sees. A message can pass SPF while displaying an entirely different From address, which is why SPF alone stops very little of what people expect it to. The practical constraint is the ten-DNS-lookup limit. Each include mechanism counts, and organizations using several mail and...

DMARC Explained: Alignment, Policies and Reports for the Security+ Exam

DMARC — Domain-based Message Authentication, Reporting and Conformance — is the layer that makes SPF and DKIM actually stop spoofing. On its own it authenticates nothing; it ties the other two to the address the recipient sees and tells receivers what to do when that fails. The gap DMARC closes This is the whole point, and it is the exam's favourite DMARC question. SPF checks the envelope sender — the address used in the SMTP MAIL FROM command. DKIM verifies a signature associated with a signing domain. Neither of them looks at the From: header, which is the only address the user actually sees. So an attacker can register their own domain, publish a perfectly valid SPF record for it, sign with DKIM for it, pass both checks — and set the visible From: header to your bank. Both mechanisms report success on a message that is entirely fraudulent. DMARC requires alignment : the domain in the visible From: header must match the domain that passed SPF or DKIM. Without alignment, ...

SPF Explained: Sender Policy Framework for the Security+ Exam

SPF lets a domain owner publish which mail servers are allowed to send mail on that domain's behalf. A receiving server checks the sending IP against that list and decides what to do if it is not there. It is one of three email authentication mechanisms the Security+ exam expects you to know together — SPF, DKIM and DMARC — and the questions usually test which one does what. How it works The domain owner publishes a DNS TXT record listing authorised senders. When mail arrives, the receiving server takes the domain from the envelope sender, looks up that record, and compares the connecting IP address against the list. A typical record: v=spf1 ip4:203.0.113.10 include:_spf.google.com -all Read left to right: this is SPF version 1; that specific IPv4 address may send; so may anything authorised by Google's record; and anything else fails. The mechanisms ip4: and ip6: authorise an address or CIDR range. a authorises the domain's own A record, mx authorises its MX ho...