View Single Post
Old 29 Jun 2017, 05:18 PM   #1
hans2010
Member
 
Join Date: May 2010
Posts: 47
Mail forwarding: good or bad?

This is a continuation of a discussion from another thread. Some interesting technical issues were discussed there, with some points that I agree with. But I disagree with the opinion that mail forwarding is "wrong" (or "broken" as stated in the cited Richweb article).

Quote:
Originally Posted by jarland View Post
People want email to just work and they want it to just work like it did 10 years ago, and frankly that isn't possible. It doesn't anymore. Everything changed in the months following Yahoo's adoption of DMARC in late 2013.

...

Email forwarding only works for people who don't care. If your email is vital for your business, you're missing very important things. There is no other way that it can happen. Read this, and keep in mind that SRS doesn't totally fix all of this, it just provides a temporary bandaid for one single aspect of the problem:

http://archive.richweb.com/why_email...is_broken.html
There's nothing "wrong" with email forwarding. First, it conforms to published internet standards (RFCs 821, 822, and their successors) and is supported by those standards as a valid use case. Second, people in the real world have actual reasons for using this feature. They are using a legitimate feature in the way it was designed to be used, and get a benefit from it.

Let's look at the above-cited "Why Email Forwarding Is Broken" article from Richweb, and see why their article is broken:

1. The article characterizes legitimate use cases of forwarding as being "impersonation," which it isn't. As I mentioned, that characterization is supported neither by the RFCs nor by the users legitimately using the feature. Labeling it as "impersonation" seems to be an attempt by the authors at spin-doctoring (i.e., resorting to pejorative wording, instead of just relying on the merits of their technical argument).

(The above is the main problem with the Richweb article, the rest are perhaps less significant.)

2. They state that SPF stands for "SenderPermitted From". It actually stands for "Sender Policy Framework."

3. In the "Rosalie" example (test.com forwards to hotmail.com), they said "test.com is now seen as a SPAMSOURCE" in the scenario described. That is inaccurate. In that scenario, while the IP address (and possibly hostname) of any server transmitting the message might be identified as a spam source (including the server that hosts the "test.com" domain, whose domain name is presumably that of the hosting provider), the name of the hosted domain ("test.com") would not be identified as such, because that domain name appears in the "To" address of the message, not the "From" address (it is the "From" addresses that get scrutinized in this kind of analysis).

4. The article is poorly formatted (has many words run together due to missing spaces).

Although Richweb claims to have deep technical experience, the above 4 points detract from my impression of them as a source of expertise on this issue. (It's also a bit humorous that, at the bottom of the article, they claim over 17 years experience, which is apparently true... but they can claim a somewhat higher number if they've really been around since 1995!).

Here's my own use case. I have my own domain (website and email) hosted on Unix-based web hosting provider. I have various configured address of the form alias@mydomain which all arrive at my webhost. There, the messages get stored into flat Unix text files, and also get forwarded to my account at FastMail (with different aliases directed to different folders in my FastMail account). There are various reasons why I do this.

A. The webhost is good for Unix-level file actions (like grep, emacs, and any other ways of manipulating/archiving/organizing files that Unix allows, which is maximal flexibility), while FastMail is good as a mail UI.

B. I like having my mail stored in two places automatically, in case I need to access something while one service is down or not accessible, or in case of accidental data loss (could be me pushing the wrong button) on either service.

C. While FastMail is my day-to-day UI, the webhost is the best "first arrival" location because they do an SMTP-level reject of unknown aliases. I can't configure that on FastMail with folder-addressing and all the various folders I have there... even if I delete the folder, the mail still gets put into the Inbox.

D. Hosting an email domain on FastMail would cost me extra, whereas email hosting for my configured domain is included in the price of my service on the webhost.

The good news is: Forwarding works well for me. And with the minimum possible spam filtering, I rarely ever see any spam (probably because I'm careful to use throw-away aliases when signing up for online subscriptions, etc.). I'm not saying everyone should do exactly what I do, I'm just saying that my use case is legitimate, and it works. Saying that there's something "wrong" with my use case has no technical merit.

Perhaps someone might say that it may not be working, that I may be missing emails and never know about them. Perhaps, but if my webhost got blacklisted for forwarding spam (such as in Spamhaus, Invaluement, etc.), then other customers who use email services on that webhost would be affected, and the webhosting company would have an incentive to get off the blacklist quickly. And perhaps that's what motivates some service providers to do what the Richweb article mentioned, "Many web hosts are now banning email forwarding to third party emailaccounts."

But the solution isn't to outlaw forwarding. That's technically weak, because it incurs what's called "functional degradation," i.e., depriving users of legitimate functionality that used to work. Email providers (like Google and Microsoft) are now some of the richest companies in the world, so they ought to spend some money and brainpower coming up with solutions that don't incur functional degradation, not just punt on the problem and say "you can't forward anymore." I should point out that mailing lists are also forwarders. You can't just say, "no more mail groups, folks, sorry."

I'm not on the payroll of those companies (not anymore, anyway), but I'm willing to help think about this problem for free! Let's see....

Well, one thing FastMail does that helps is that they actually have an account setting where I can specify one or more hosts that I receive forwarded mail from. The form says, "Use only if forwarding email to FastMail from another system. The Received headers of these hosts are parsed to find the true email source." It seems that they're actually thinking about this problem with the customer in mind!

I think the ultimate solution has to do with reputation management. I think we're part of the way there, with clearinghouses such as Spamhaus and Invaluement. When an MTA receives a message, it should be able to assess a reputation depending first on who the immediate sender is, in combination with whatever upstream reputation assessment that sender passes along (ideally involving the reputation of the individual who sent the message, e.g., if I've been a paying customer for years with a service provider, they should attach a higher rating to my message than if I just signed up that day). Messages with low or unknown reputation at any link in the chain get rated lower, and then their messages might get throttled, filed separately, or rejected, depending on the rating, along with service provider policy and end-user preferences. Importantly, we should give the end user maximum choice over how they want dubious messages handled (e.g., FastMail has settings for what to do with messages at higher spam scores).

At the technical level, I'm not sure if this should involve Authenticated SMTP, SMTP over SSL, more reputation clearinghouses, or something else (they're not paying me enough to come up with the complete solution!). But I think it's a combination of things that could evolve from this point (perhaps along the lines I suggested above).

Quote:
Originally Posted by jarland View Post
it's companies like Yahoo, Microsoft, and Google making these changes to the industry. The rest can either play ball or ignore customer complaints. All because people who should probably just be using aliases insist on forwarding email.
I'd change that last statement to, "All because some companies that carry weight in the email market aren't willing to do the due diligence and come up with a sound technical solution that keeps the user's legitimate needs at a priority."
hans2010 is offline   Reply With Quote