[jarland]

Originally Posted by hans2010

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).

It's not an opinion. I don't mean to be that guy that's like "I'm always right" but there are a few things I know to be true in life without question. Up is up, down is down, IMAP was not designed for sending email, and forwarding is a feature that is on life support at best. People who desperately want forwarding to be a perfect thing, as well as providers who want to market to the large number of potential customers that demand this feature, will try to disagree for selfish reasons. I speak what I know, not what I wish, and it isn't intended to convince you to buy something. In fact, I sell something that I would actively say "Do not buy" if you insist on using email forwarding. I'll let you use it, I'll try to keep it up, but I'll point back at the customer when they say "I didn't receive an email that I really needed" and say "Then you should be treating your email as though it is important and not subjecting it to such a thing."

There's nothing "wrong" with email forwarding.

Incorrect. You WANT there to be nothing wrong with email forwarding. So do I, but it doesn't matter what I want. I'm not the CEO of Google, Microsoft, Yahoo, Verizon, AT&T, or any other number of major providers that have rendered it to a state ranging from intermittently functional to completely broken.

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.

Here's an RFC for the use of carrier pigeons: https://tools.ietf.org/html/rfc1149

It doesn't matter what an RFC says. You can't shout at your monitor to Google or Microsoft "You're violating RFC" and expect change. RFC doesn't make reality, and anyone is free to violate them at any time. Microsoft very frequently accepts emails with a positive return code and then never delivers them, no error or bounce. This violates RFC standards. They don't care.

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).

No offense intended here, but I don't think you understand how SPF is used. Violating someone's SPF policy is absolutely impersonation. If yahoo.com says "Emails from yahoo.com ONLY come from these IP ranges" and you send an email from another IP range stating it to be from a @yahoo.com address, you have spoofed/impersonated their domain. It's their domain, they define what is impersonation, and most email providers respect this. How you feel about it is irrelevant, SPF defines where email can be sent from and providers respect it, therefore it is fact.

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

That's very minor, and doesn't change that SPF is relevant, or what it does.

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).

You are incorrect, but you may not know why yet. I'll explain two reasons this might be:

1. Forwarding MTA might add the domain elsewhere in a header that recipient server doesn't recognize shouldn't be included in content filtering/learning.
2. SRS, which is vital for forwarding, will have the email sent from the recipient domain to pass SPF. Recognizing this at the end point is not a promise not to filter based on it, and some do. Whether intentional or not, it happens.

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

It didn't at one point, but something happened and that was the result. Regardless, I don't think accidental spacing issues when performing some kind of change to the blog later indicates any lack of experience or intelligence.

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!).

I have quite a bit of experience and I chose that article for a reason. I didn't learn from it, I used it to express things that I already knew from managing mail servers at scale at HostGator, and continuing to do so at MXroute. I know what I say to be true because I deal with it. I also deal with people trying to project their feelings onto it regularly, telling me that I'm wrong because they so desperately want me to be. Obviously my patience for that grows a bit thin over time. I'm the one dealing with the problems and trying to prevent them from impacting other customers, where they usually do and providers just shrug their shoulders.

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.

What if that one marketing email you get is the last straw for one particular IP and the next customer gets their email rejected at random when trying to send an email to their family member? You wouldn't know. I would. That's the reality I deal with. Being on the receiving end of consistently good dice rolls does not mean that you have found me, the one actually dealing with this stuff as a server admin, to be wrong.

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."

Precisely.

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."

That's cool, but how do you intend to make sure that they do that? How do you advise that anyone does that? If you assume that there's some super secret meeting that one can attend, I assure you there is not.

My reply was too long for this forum, you can read the rest here:
https://paste.jarcloud.pw/ejolaqupot.sql