[hans2010]

Originally Posted by jarland

It's not an opinion. I don't mean to be that guy that's like "I'm always right"

OK, then let's say I disagree with the indicated statement (not "opinion").

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, if they "rendered" something broken that used to work, it doesn't mean that the thing in question is flawed technically. It means that some companies created flawed implementations that didn't used to be flawed. Following your logic, one would say "chocolate is bad for you" if two or three of the major suppliers started putting toxins in it. In that case, the statement may be valid in some sense, but I'd still disagree because it inaccurately characterizes the problem.

Second, the "range" is actually wider than you describe (that is, the range goes to far better than "intermittently functional"... even if it didn't where you worked). I do comparisons of messages received on the host that initially receives my mail vs. the host I forward to. I can tell if something failed to forward. I estimate that I've lost less than one message per 10,000 on a forward. The one I can think of was because the sender's domain was on the Invaluement blacklist. My webhost doesn't check that blacklist, so it accepted the message, but FastMail does, so they rejected the forwarded message (not because it was forwarded). Now, if I had done what you advocate and not do any forwarding, I'd never know that the sender was on the blacklist. Good thing I knew, because I was able to help them get off it (it was an arts school with nobody technical working there).

Not trying to argue with you, just adding a data point that you might not have known existed (someone using forwarding successfully in the present age). Revising your sentence for accuracy, it would say, "ranging from nearly flawless to completely broken."

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

Non-sequitur. I said "Internet standards." That RFC isn't on the standards track.

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.

You may be interested to know that the very companies you mentioned actually collaborate on these specifications and publish them as RFCs. Strange, since, according to you, they don't care about them.

What matters to me more is if the service providers I pay money to care about the standards. I have found that they do, and that's backed up in action by implementing systems that do, in fact, implement those standards competently (or so has been my experience with them). I'm not on any of the major providers you mentioned, so I don't care what they do other than allow me to get mail to/from their users via my service providers. I haven't had any trouble getting mail back and forth to people who are on those major services. I don't interact with the general public, mainly just people who I see in person or who I might talk with on the phone (and various businesses like my bank, etc.). So if they ever had trouble getting mail to me, I'd have heard from them about it by now. Apparently, the major providers implement the standards well enough that my service providers have a high success rate getting mail back and forth to them... even with the forwarding I'm doing.

Again, not arguing, just adding a data point that you apparently thought could not exist.

No offense intended here, but I don't think you understand how SPF is used.

Actually, I do. No offense, but I don't think you understand how to tell that someone understands!

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.

I know you don't care about RFCs, but those documents don't label people who do forwarding with pejorative labels like spoofers and impersonators. I guess if you and Richweb are higher authorities than the RFC authors then that's that. But I disagree with it.

Also, if you're not relying on the RFCs, then I don't know what you're referring to when you say "SPF defines". And if you are relying on the RFCs, then your statement is inaccurate, in that they recognize forwarding as a legitimate action and recommend strategies for getting SPF to work in cases where forwarding is happening. And they do not refer to it as spoofing/impersonation.

Maybe you should cite what definition of SPF you are referring to, because it's certainly not the one I found.

I agree that how I feel about it is irrelevant, except when I make choices what service providers I give my money to. And I'm satisfied with the providers I have.

Being on the receiving end of consistently good dice rolls

It's not the dice rolls. It's me being picky about what service providers I give my money to, and how competently they deliver their services. They've done a good job, and they continue to do so.

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

I already said that points 2, 3, and 4 were relatively minor. Still, it was my experience when I was in the industry that the people who knew what they were talking about didn't make up their own definitions for acronyms (like the Richweb article did). Plus, they knew how to represent themselves professionally, meaning that their writings (either online or on paper) weren't littered with errors that a simple copyedit would fix (as seen in the Richweb article). These things definitely correlated to technical competence.

That was just my experience. Yours may be different.

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

Those two reasons weren't mentioned in the Richweb article, they just presented a more general forwarding case. If they meant to be discussing a special situation where the breakage occurs (i.e., that doesn't occur in the general case), then a competent technical article would've explained that.

In any case, I can add another data point for you. I've been using my own domain in combination with the forwarding arrangement I described previously (which is very similar to the 'Rosalie' example) for 15 years. In all that time, even though I was a recipient of some amount of spam over that time, I never had the experience where my domain name got blacklisted as a result of appearing in the "To" header.

Again, not disagreeing with you. Just adding a data point that shows that the system does work, at least on competently designed servers.

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.

The secret meeting is called IETF. If you want to advocate that forwarding be prohibited, you should go there to make your case. You'll get more mileage by advocating your position there than by writing about it on this forum.

I'm no longer on the payroll of any company that's involved in email, so I probably won't show up there myself. I'm just an end user, hoping that the people who are paid to work on this stuff work out a solution that's in our best interests, not just punt on the problem and impose functional degradations on us all. Yes, it may be hard work, but that's what the 'E' in 'IETF' is for. It means to think and work constructively, not just give up. In my previous message, I pointed out how FastMail is looking at the problem constructively, and alluded to how further progress can be made. Being optimistic, my prediction is that the ultimate solution will be something along those lines.

I stand by my earlier statements.