Quoting Simon Hobson (linux@???):

> > Sounds like a problem local to you.
>
> No, not in the least bit "local to me". I will be generous and assume
> that you simply misunderstood what I wrote - it happens a lot :-(
>
> Prior to SPF, it was perfectly OK to (for example) :
>
> Have an account (lets say fred@???) so that fred can have an
> email address that "goes with" his website.

So, when I said 'local to you', I meant 'local to people who want to use
practices that amount to forging the domain owner's Internet domain, in
ways many domain owners including me no longer find tolerable and wish
to make not work, i.e., to be rejected as forgeries. Since we're using
the hypothetical example of Fred, my assessment then becomes 'Sounds
like a problem local to Fred.' And since, as detailed below, no
Fred-types are among legitimate users of _my_ domains' mail, I'm not
only fine with illegitimate Freds being unable to successfully forge my
domain, I'm very happy with that outcome.

> For reasons we never understood*, Fred is adamant he is not prepared
> (even if we configure it for him) to have a second account in his mail
> client to directly collect mail from our mail server using POP or
> IMAP. He just wants mail to arrive in his inbox. So instead we simply
> forward his mail to his regular account - tends to be
> "somegibberish@???" and things like that). Of course, some
> wanted "sales@...", "support@...", and so on as well - though mostly
> these clients were prepared to do it without forwarding to an external
> account. For many years that worked just fine. ONLY when more players
> started implementing SPF did it break.

Basically Fred relied on forging the various domains where he has
accounts for mail, in the sense of originating mail from arbitrary
originating IP addreseses on his outbound mail, IP addresses that the
domain owners have no particular wish to be accepted as sources of their
domains' mail (e.g., someone else's MTA).

I have no doubt that some Internet domain owners remain oblivious to the
reputation problem that results when UCE and other junk can believably
impersonate their domains as the claimed sources of outbound mail -- and
those oblivious domain owners can make Fred happy as long as that
arrangement continues to work for both.

The legitimate users of my domain linuxmafia.com (among others) do not
include any Freds, because I informed all my users around the year 2000,
"Hey, if you're used to sending out your [myaccount]@linuxmafia.com
accounts via SMTP lists _other_ than linuxmafia.com itself, please be
advised that, starting now, I'll be doing my best to ensure that any
such mail fails and is rejected. Please switch to originating
linuxmafia.com mail from the linuxmafia.com server ONLY. Thank you.'

It's a small operation with only a small number of clueful users.
Larger operations offer roving IP-address origination _of their domain's_
mail _from their authenticated users_ via the newer SMTP Submission port,
587/tcp.

https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587/

If one of my users was a Fred, and he wanted his outbound linuxmafia.com
mail to be acceptable to end-destinations irrespective of what IP
address sent it outbound on 25/tcp, I'd say 'Sorry, Fred, not with my
domain.' If you want to do that, feel welcome to register your own
domain and you can risk its reputation any way you want.




> We didn't change anything, others implemented policies explicitly
> designed to break it.

By 'others' you mean domain owners, and by 'break it', you mean break
deliverability of mail from unauthorised originating IPs forging those
owners' domains.

And that's the thing. Fred (and you) don't own those domains.
Therefore, you don't decide those domains' SMTP deliverability policies,
because -not yours-.

If you're unclear on the meaning of 'not yours', try to forge SMTP from
linuxmafia.com, and the outcome will clarify the concept.


> BTW - I did try Sender Re-Writing (this was before DMARC & DKIM were
> popular).

SRS was a last-ditch attempt to preserve the ability of ~/.forward and
/etc/aliases ancient-style forwarding to function for cross-domain
delivery in the modern age of domain owners no longer being inclined to
permit SMTP forgery. IMO, it was never worth the trouble. By 2000,
the handwriting was on the wall that ~/.forward and /etc/aliases
cross-domain forwarding had been a casualty of the war on spammers' and
others' forgeries, so with almost no regret I ceased using those two
antique forwarding methods (except intra-domain).


> Again no. It's not about who sends mail purporting to be me, it's
> about allowing me to legitimately forward mail from "some random
> person" to one of our clients - where that client just wants the email
> to appear in his inbox.

Basically using someone else's MTA as a relay for your client without
prior arrangement. Guess what? Open relays became unacceptable even
earlier than forgery did. And there's an ambiguity you're concealing by
your phrase 'my client'. It appears this Fred-ish person is not
originating mail purporting to be from _your_ domain, but rather some
non-yours domain. If it were your domain the Fred-ish person were
purporting to originate from, then it would be entirely within your
power to either declare in an SPF record that his preferred SMTP senders
are authorised senders for your domain, or (more your style) elect to
have no SPF record, not stating any wishes about what originating MTA
are legitimate or not for your domain.

However, since you are complaining that 'your client' is being foiled in
his behavour by SPF records, the implication is that the sending domain
being asserted in your client's outbound mail is someone else's domain
-- a domain owned by someone enforcing his/her policy.

That is not Fred's / your client's prerogative, nor is it yours.


> Yes, I understand there's an argument that it's "not legitimate", but
> it was long established practice and it broke.

Open relays used to be 'established practice', too. Guess what? MTA
operators who cared about their domains' reputation put an end to them,
in the sense that operators who didn't found themselves in DNSBLs and
could not deliver most places.

> And it broke in exactly the ways that people knew SPF would break
> before they implemented it.

Bullshit. You basically assumed your and your users right to continue
to abuse other people's domains. Some of those domains' owners have
decided that cannot continue. This is the concept of 'not yours' at
work. You should have long ago figured this out. And frankly, I do not
appreciate spending time going over the obvious.


> > I doubt your premise that SPF 'breaks' anything
>
> It breaks mail forwarding as already mentioned.

If people cannot forge linuxmafia.com mail from other IPs that I don't
authorise, I consider that A Very Good Thing, and do my best to make
sure that outcome happens. If other people say they dislike my acting
to ensure that outcome, if I'm feeling polite, I explain the concept of
'not yours' to them. If not, I ignore them.


> It breaks mail list managers configured as they were mostly previously
> configured.

Incorrect. You made this same error several years ago, the last time we
discussed this, and I showed you in detail that SPF has zero adverse
effect on MLM forwarding, because of envelope rewriting automatically
carried out upon passage through the MLM and retransmission through the
outbound MTA to subscribers.

That aspect is what distinguishes MLMs from simple reflectors such as
~/.forward and /etc/alias entries, which do _not_ supply new envelopes.
Hence, MLM mail from subscriber fred@??? via Mailman mailing
list test@??? arrives at subscribers' receiving MTAs able to
pass SPF validation for _linuxmafia.com_, the domain in the SMTP
envelope. Whether it still passes SPF for exaample.com is irrelevant,
because _SPF validates the envelope sender_.

I'm embarrassed on your behalf that, even after this was already
explained to you in detail, several years later, you're still repeating
the very same error to the same person, a person who unlike you
understands why MLMs by the nature of their implementation are
unimpaired.


> I have no technical argument why you should not do what you like with
> your own mail, but ...

Since I've not said anything other than

This meets my needs perfectly:

:r! dig -t txt linuxmafia.com +short
"v=spf1 ip4:96.95.217.99 -all"

...you are extremely out of line. Because my domain is Not Yours.

> So lets say you have a user jim@???, who sends an email to
> fred@??? - Fred being one of our clients who chooses not to
> configure example.com on his mail client.

I would have straightened out Jim in the year 2000. Jim was briefed
that he is no longer permitted to forge my domain's mail from other SMTP
source locations, and knows this.

If Jim nonetheless tries to do so, fails, complains to me and explains
what he tried, I'll say 'Excellent. Works as designed.'

> By configuring SPF, you have removed Fred's ability to receive mail
> from Jim - at least in the manner in which he wishes to receive it.

Fred is not my problem, as Fred is not my user. _Jim_ is, in your
hypothetical, and has been (long ago) briefed about crazy stuff that he
probably shouldn't try and that I've done my utmost to ensure will never
work -- for the reason that I'm acting to protect my domain's
reputation.


> As an analogy (though I admit a rather poor one)....

I'm not even going to bother outlining the ways the Royal Mail's
forwarding service is an utterly unsuited and obviously distortive
analogy, but it starts with the fact that the customer has to paste a
76p stamp on each envelope.