Postmaster/Webmaster

Domains Served

I serve as “postmaster” and “webmaster” for the following domains, originally so I could increase my own understanding of the challenges of administering an SMTP server that is heavily targeted by spammers:

burleyarch.com: “James Craig Burley, Software Architect”
My consulting site. Hosts this blog.
jcb-sc.com: “James Craig Burley, Software Craftsperson”
My former consulting site; its website now forwards to my current consulting site. I’ve owned this domain name for nearly two decades. It became a target of spam, vermin, and joe jobs, and accounts for the vast majority of incoming email on my system. Being made an unwitting target of joe jobs has, more than any other factor, caused me to devote substantial thought, energy, and effort to coming up with solutions to the problems of spam and vermin.
kilmnj.com: “They float, but kilmnj is fixed.”
The home for my GNU FORTRAN 77 (g77) “Legacy” Site, as well as of anything else relating to what I call “geezer tech” that I find worthy of publishing.
llamail.com: A “placeholder” domain name also used as the primary name for the VPS that serves these domains.
theburleys.net: “The Burley Family”
Our family’s household domain name. This domain is not yet the target of much spam or vermin.
jcbmail.net, jcbmail.org, lamail.org, llamail.org, urip.org: Various “placeholder” domains for which I have tentative plans to develop.

Email (SMTP) Service

Email to the domains I serve is handled by my own heavily-patched version of qmail version 1.03, one of the most widely-deployed MTAs on the Internet.

Email from the domains I serve is never spam or vermin, although spam or vermin might claim to come from one of my domains.

I don’t use SPF to filter incoming mail, but I do publish SPF records for the domains I host.

If you are unable to inject legitimate mail into my server, contact me via the email address I provide as the contact for my domain names.

My servers don’t send spam, viruses, etc., though such material often “pretends” to come from domains I control.

Email header lines such as “From:”, “Reply-To:”, and “Return-Path:” can be easily forged by a sender, as can “Received:” in certain cases. Don’t trust them!

My (personally patched, so don’t blame djb) installation of qmail no longer bounces misaddressed emails. Instead, it either rejects them or deposits them in a special mailbox for me to review when I have time for any truly mis-sent emails, which I would then “bounce” by hand.

Though that makes my life a bit more difficult, I feel it’s a more reasonable choice than to continue bouncing lots of spam and vermin to innocent third parties (victims of joe jobs, like myself), and a more secure alternative than to reject all such email during the SMTP conversation (though many people, and MTAs other than vanilla qmail, prefer that approach).

“It Wasn’t Me”

The following was written by me many years ago, but might still have some relevance:

I don’t send spam, vermin (viruses, worms, trojan horses), or any other forms of UBE or UCE, sometimes called UBM or UCM (substitute “Mail” for “Email” in the acronyms). But you might think I send such mail if you innocently trust information in such email you might receive.

Since early 2003, a deluge of UBE has been delivered to a huge number of recipients with an envelope sender, “From:”, or “Reply-to:” address having a domain name of jcb-sc.com, which is the domain name of this web site.

In fact, all spam and vermin appearing to come from this domain are forgeries; they actually come from somewhere and someone else not under my control. Sometimes these are called “joe jobs”; in some cases, they are referred to as “phishing scams”, especially when the message contains forged URLs or other contact information that might convince an unsuspecting recipient to provide personal information or other valuables to the actual originator rather than to the forged originator.

These forgeries are akin to notes or letters written by A, addressed and sent to B, but with return addresses (or “From:” headers) saying they were written and/or sent by C, yet without C’s permission. They might appear to use C’s letterhead, include C’s contact information, or even include contact information that appears to be C’s but in fact belongs to an agent for whoever is doing the forgery.

(For example, if C’s address is widely known to be “P.O. Box 1972, Lincoln, NE”, a clever forger might obtain a similar box number and advertise that, in the hopes that unsuspecting recipients deliver valuables to, for examples, “P.O. Box 1792, Lincoln, NE” or “P.O. Box 1972, Lincoln, ND”.)

In such cases, C has no ability (even if C has the knowledge) to prevent A from sending such communications; the onus is on recipients, such as B, to not assume that C sent the message, regardless of the claim on the message itself or made by A. (This is true regardless of whether A claims to merely be passing along a message from C as a trusted intermediary, or convinces an intermediary that B actually does trust to relay the message to B as if it originally came from C, which is easy to do if that trusted intermediary does not authenticate the return address.)

C cannot and should not be in any way held responsible for the fact that such forgeries are occurring, unless C also agrees to accept the authority to take action to stop it. (An example of such authority to stop forgery is that which is granted publishers of monetary currency, such as the US Government.)

For now, the only such authority I have accepted is to publish SPF information for my domains, although few SMTP relays or servers actually use that information to reject forged email (which is probably best, as I don’t recommend SPF for that purpose).

With Internet mail, the envelope sender (usually shown as “Return-Path:”), “From:”, and “Reply-To:” addresses, contained within the full headers of spam or vermin email, are rarely authenticated before email reaches your mailbox. Proposals (such as SPF and DomainKeys) have been made to address this, and have been partially implemented, but they are imperfect, and risk making Internet mail less flexible, less useful, and less reliable.

False return addresses are forged sometimes to conceal the identity of the actual senders, always to avoid the huge number of delivery-failure reports and abuse complaints that would ordinarily result from sending out vast quantities of UBE. So those reports and complaints are delivered to, or made about, whoever actually “owns” the forged addresses — such as myself in the cases of these “joe jobs” — despite their having not been involved in the forgeries being circulated in the first place.

(You might wonder why people advertising a product for you to buy would nevertheless forge their return addresses, when potential customers might use them to request further information on, or order, a product. Indeed, many spammers need you to be able to buy a product from them, but not all of them do — some are merely proselytizing a point of view — and vermin authors usually have no such need for their vermin to provide useful return addresses. Meanwhile, the spammers who want potential customers to contact them usually prefer to provide contact information via the spam itself, such as URLs or phone numbers, which they assume will be used mostly by people genuinely interested in their products.)

If you are interested in tracking the perpetrator of any spam or vermin you have received, an Internet search engine can help you find a number of resources with information about finding out who has really sent you the spam or vermin.

There is no need to tell me you received any such forgeries; I get enough email telling me about this already!

SPF

Though I don’t configure my MTA to use SPF at all, I do publish SPF records for the domains I host that send outgoing mail:

v=spf1 a a:llamail.com -all

That Version 1 SPF (“v=spf1“) record specifies that all my outgoing email is sent from:

(“a“) the same host listed as the server for the domain in question (such as jcb-sc.com)
(“a:llamail.com“) my colocated server (llamail.com)

I don’t recommend using SPF to block incoming email, or to filter it such that it might end up accepted, unread, and unbounced. But I hope that, by publishing my own SPF records, those who use SPF for these purposes will accept and properly prioritize emails that actually do originate from my domains.

Failings of SPF

The reasons I don’t recommend using SPF to block incoming email are substantially and persuasively addressed by Jonathan de Boyne Pollard, who claims SPF Is Harmful, though I now disagree with any implications that IM2000 Internet Mail is preferable to SMTP (and yet am “on the fence” with regard to IM2000 compared to SMTP with widespread adoption of SPF).

I do believe forgery is a significant problem on the Internet. In fact, my email addresses and domain names have often been “hijacked” by forgers who send spam (see above). But I consider SPF to be an insufficiently robust design and implementation to address this problem within the present Internet email system (which is based on SMTP), and I’m not convinced any SMTP-based system can (or even should) be sufficiently secured against forgery.

SPF and similar authentication schemes, such as DomainKeys, can be used to “tag” incoming email rather than just block it. A benefit of such tagging might be that incoming mail tagged as “not authenticated” or “likely forgery” is delivered to a lower-priority “inbox” for a recipient. As long as the recipient ultimately reads the email and can decide whether it is worth following up on, improperly tagging email (as a result of any of SPF’s problems) isn’t necessarily a big problem.

However, if the result of an improperly tagged email is that the email is never read and never bounced, a legitimate sender of such email is left believing either the email has been received and read, or that no email he sends is necessarily getting through.

And that represents a huge problem with almost any SMTP-based anti-spam measure, such as SPF: to the extent they increase the likelihood that legitimate mail is “dropped” (accepted, but never delivered nor bounced back to the sender), they decrease the sender’s confidence in the system and the usefulness of the bounce mechanism (which is an expensive mechanism in the first place). Absent some other means of verifying that a message got through (perhaps in the form of the recipient responding to the message), SMTP provides no reliable means to verify that a message has not been dropped (essentially, deleted).

Other problems with SPF and similar schemes include excessive reliance on the DNS system, which can increase latencies (add delays) to the receiving of incoming email by each SMTP server that handles it.

I consider SPF to be just one of many Challenge/Response systems intended to improve email exchange, all of which degrade it in one way or another for legitimate use without sufficiently devaluing it for abuse by spammers or vermin authors.