For subscribers to our free weekly mailing lists compiled from articles that appear at the TidBITS Web site, I’m offering an administrative heads-up about a change in how we will be sending out email. Starting with TidBITS #1065 next week, our issue email headers will be slightly different, a move that we didn’t anticipate, but one that has turned out to be necessary for bounce processing in our new system to work.
I’m providing this advance warning because if you have whitelisted email from [email protected] in your spam filter, it’s possible that next week’s issue—which will come from a different address at our domain—will be marked as spam. If TidBITS doesn’t arrive next week, that’s probably why, and you should go spelunking in your spam folder. Also, if you move TidBITS issues to another mailbox via a rule that keys off [email protected] appearing in the From line, that will need changing too. Sorry for any inconvenience!
In an ideal world, we would make the change and everything would just work with no need for you to do anything. But assuming that Murphy’s Law remains intact, here’s what you might need to know.
From: TidBITS Editors <[email protected]>
That [email protected] address is what you’ll want to add to any spam filters that allow you to whitelist (approve automatically) messages from specific senders. However, it’s not the best way to filter TidBITS issues to a different mailbox. For that, I recommend using a rule that relies on the List-Id header. Our list headers are specific to each version of TidBITS; you can see which one you receive by viewing the full headers for the message.
List-Id: TidBITS Text Issue List <text.issue.tidbits.com>
List-Id: TidBITS HTML Issue List <html.issue.tidbits.com>
List-Id: TidBITS Text Announcement List <text.announce.tidbits.com>
List-Id: TidBITS HTML Announcement List <html.announce.tidbits.com>
Reply-To Changing Too — Also changing next week will be the Reply-To address in the issue. The new address will not be read by a person, but will instead generate an auto-reply that explains the best ways to contact us for different purposes.
Why the auto-reply? The simple fact of the matter is that there are a lot of different ways to contact us, and which is most appropriate depends on the situation. For instance, if you’re writing to comment on an article, we’d much rather have you leave a comment on the article itself than send us email. And if you’re really shy, you can always email an author directly—using a link next to the byline on every article—or ping them via Twitter (check our Contact Info page for staff details).
If you have a problem with our Web site or with our email issues, it would be great if you could ask on our TidBITS Get Satisfaction site, where we can reply in public and others with similar questions can benefit from our answer to you. If the problem is something you think I should know about right away, ping me via Twitter.
On the other hand, for questions about your account, where we can’t really help you unless we know your email address, private email makes more sense than Get Satisfaction. (The same goes for Take Control—general questions and suggestions are best sent to the Take Control Get Satisfaction site, whereas account-specific questions should be sent via private email.)
And if you have a technical question that’s unrelated to a particular TidBITS article or even TidBITS itself, you’d be best off asking in our TidBITS Talk discussion list, though it now limits posts to subscribers to block the constant onslaught of spam.
The MTA Behind the Curtain — I realize this next bit gets very specific, but since we were surprised by this situation, I wanted to share our findings in case anyone else were to run into a similar problem. (And if you don’t know or care what an MTA is, or how mail servers operate, there’s no need to keep reading.)
When we were using Web Crossing, it acted as both the mailing list software (generating the actual messages to send out) and as the mail transfer agent, or MTA. Because it wore both hats, Web Crossing was able to customize the headers of each individual message to identify and process bounces. In particular, Web Crossing added a customized Return-Path header, as in:
Return-Path: <[email protected]>
And notably, that header was different from the From line:
From: "TidBITS Editors" <[email protected]>
That’s important because only the MTA can insert the Return-Path header. Since our homegrown TidBITS Publishing System is acting as the mailing list software, and handing messages off to sendmail (via a library) to deliver, sendmail inserts the Return-Path header automatically, basing it on the From header. Thus, both the Return-Path and From pointed at [email protected] Although it’s conceivable that sendmail could be configured to insert a different Return-Path header, that’s apparently not possible with the library that we’re using to connect sendmail to the TidBITS Publishing System.
Since we had always had the From address be [email protected] and didn’t change it for our first use of the new system, we were a little shocked when bounces came back to that address rather than to the address listed in the Errors-To header. It turns out that Errors-To is not a standard, unlike Return-Path, so it worked in some cases, but by no means universally.
Anyway, we believe the solution is simple—to set the From line to contain an address that will be replicated into the Return-Path header and that can receive and process bounces appropriately. But we figured that many people would either be whitelisting [email protected] or filtering based on it; hence this message. Glad you asked?
We now return you to your regularly scheduled issue of TidBITS.