SPAM

Spam is the abuse of electronic messaging systems to send unsolicited bulk messages indiscriminately. While the most widely recognized form of spam is e-mail spam, the term is applied to similar abuses in other media: instant messaging spam, Usenet newsgroup spam, Web search engine spam, spam in blogs, wiki spam, Online classified ads spam, mobile phone messaging spam, Internet forum spam, junk fax transmissions, and file sharing network spam.

Spamming remains economically viable because advertisers have no operating costs beyond the management of their mailing lists, and it is difficult to hold senders accountable for their mass mailings. Because the barrier to entry is so low, spammers are numerous, and the volume of unsolicited mail has become very high. The costs, such as lost productivity and fraud, are borne by the public and by Internet service providers, which have been forced to add extra capacity to cope with the deluge. Spamming is widely reviled, and has been the subject of legislation in many jurisdictions.

People who create electronic spam are called spammers.

E-mail authentication

DKIM: DomainKeys Identified Mail

DKIM website

DomainKeys Identified Mail (DKIM) is a method for E-mail authentication, allowing a person who receives email to verify that the message actually comes from the domain that it claims to have come from. The need for this type of authentication arises because spam often has forged headers. For example, a spam message may claim in its "From:" header to be from sender@example.com, when in fact it is not from that address, and the spammer's goal is to convince the recipient to accept and to read the email. Because the email is not actually from the example.com domain, the recipient cannot have any effect by complaining to the system administrator for example.com. It also becomes difficult for recipients to establish whether to give good or bad reputations to various domains, and system administrators may have to deal with complaints about spam that appears to have originated from their systems, but didn't.

DKIM uses public-key cryptography to allow the sender to electronically sign legitimate emails in a way that can be verified by recipients. Prominent email service providers implementing DKIM (or its slightly different predecessor, DomainKeys) include Yahoo and Gmail. Any mail from these domains should carry a DKIM signature, and if the recipient knows this, they can discard mail that hasn't been signed, or that has an invalid signature.

DKIM also guards against tampering with mail, offering almost end-to-end integrity from a signing to a verifying Mail transfer agent (MTA). In most cases the signing MTA acts on behalf of the sender by inserting a DKIM-Signature header, and the verifying MTA on behalf of the receiver, validating the signature by retrieving a sender's public key through the DNS.

The DomainKeys specification has adopted aspects of Identified Internet Mail to create an enhanced protocol called DomainKeys Identified Mail (DKIM). This merged specification is the basis for an IETF Working Group which has guided the specification towards becoming an IETF Proposed Standard.

SPF: Sender Policy Framework

SPF website (Sender ID)

In computing, Sender Policy Framework (SPF) allows software to identify messages that are or are not authorized to use the domain name in the SMTP HELO and MAIL FROM (Return-Path) commands, based on information published in a sender policy of the domain owner. Forged return paths are common in e-mail spam and result in backscatter. SPF is defined in RFC 4408.

Normal SMTP allows any computer to send an e-mail claiming to be from anyone. Thus, it is easy for spammers to send e-mail from forged addresses. This makes it difficult to trace back to where the spam truly comes from, and easy for spammers to hide their true identity in order to avoid responsibility. Many believe that the ability for anyone to forge sender addresses (also known as Return-Paths) is a security flaw in modern SMTP, caused by an undesirable side-effect of the deprecation of source routes.

SPF allows the owner of an Internet domain to use special format of DNS TXT records or the newer SPF records to specify which machines are authorized to transmit e-mail for that domain. For example, the owner of the example.org domain can designate which machines are authorized to send e-mail whose sender e-mail address ends with "@example.org". Receivers checking SPF can reject messages from unauthorized machines before receiving the body of the message. Thus, principles of operations are quite similar to those of DNSBL, except that SPF leverages the authority delegation scheme of the real Domain Name System.

The sender address is transmitted at the beginning of the SMTP dialog. If the server rejects the sender, the unauthorized client should send a bounce message to that address. If the server accepts the sender, and subsequently also accepts the recipient(s) and the body of the message, it should insert a Return-Path header in the message's body in order to save the sender address. While the address in the Return-Path often matches other originator addresses in the mail header like "From:" or "Sender:" this is not necessarily the case, and SPF does not prevent forgeries of these other addresses.

Spammers can send e-mail with an SPF PASS result if they have an account in a domain with a sender policy, or abuse a compromised system in this domain. However, doing so makes the spammer easier to trace and prosecute.

The main benefit of SPF is to people whose e-mail addresses are forged in the Return-Paths. They receive a large mass of unsolicited error messages and other auto-replies, making it difficult to use e-mail normally. If such people use SPF to specify their legitimate sending IPs with a FAIL result for all other IPs, then receivers checking SPF can reject forgeries, reducing the amount of back-scatter.

SPF has potential advantages beyond helping identify unwanted e-mail. In particular, if a sender provides SPF information, then receivers can use SPF PASS results in combination with a white list to identify known reliable senders. Scenarios like compromised systems and shared sending mailers limit this use.

FAIL and forwarding
SPF does not allow plain message forwarding. When a domain publishes an SPF FAIL policy, then legitimate mails sent to receivers forwarding their mail to third parties can be rejected and bounced if

the forwarder does not rewrite the Return-Path, unlike mailing lists, the next hop does not white list the forwarder, and this hop checks SPF. This is a necessary and obvious feature of SPF – checks behind the "border" MTA (MX) of the receiver cannot work directly.

Publishers of SPF FAIL policies must accept this potential problem. They should test (e.g., with a SOFTFAIL policy) until they are satisfied with the results. See below for a list of alternatives to plain message forwarding.

HELO tests
For an empty Return-Path as used in error messages and other auto-replies, an SPF check of the HELO-identity is mandatory.

With a bogus HELO identity the result NONE would not help, but for valid host names SPF also protects the HELO identity. This SPF feature was always supported as an option for receivers, and later SPF drafts including the final specification recommend to check the HELO always.

This allows to white list sending mailers based on a HELO PASS, or to reject all mails after a HELO FAIL. It can also be used in reputation systems (any white or black list is a simple case of a reputation system).

Check SPF
The check can be done via the following link.