Rick Moen <rick@???> wrote:

>> Regardless of the arguments for and against which have been done to
>> death for long enough, SPF did predictably break email in many ways -
>> some of which I used to use, and some which my clients used to use.
>
> 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. 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. We didn't change anything, others implemented policies explicitly designed to break it. AFAIK there is no simple way around that, and customers took it that our system was broken regardless of how we tried to explain what the problem was and ways to get around it (they still won't countenance adding a new account to their mail client though).

* If you ever think you understand the mindset of clients, I think the universe reconfigures to generate new and "more interesting" ones :D And as for the mindset of developers who simply couldn't or wouldn't understand the instruction "I will generate you a new email account login for each website**, DO NOT REUSE this login on other sites", perhaps I'd better not go there !
** I did rate limiting and quotas on a per-account basis (useful first line of defence, limits extent of the damage if a site gets hacked), and it also allowed me to disable an individual account (rather than a whole webserver) if needed.

BTW - I did try Sender Re-Writing (this was before DMARC & DKIM were popular). However, my technical skills are not up to writing software to do it myself. There was software to do it with Postfix - but it fundamentally conflicted with other software we were already using and we'd have had to stop using what was probably our most effective anti-spam measure. When I did a quick search to check I'd got the right name for that, I found that Microsoft supported it in O365 - which was a bit of a surprise.

> Possibly you wish to originate port 25 mail on IP addresses you are not prepared to declare in an SPF RR for reference by SMTP receivers.

No at all, see above about assuming you simply misunderstood what I was trying to say.

> Like, maybe your users think it's still 1995 and that they ought to be free to originate outbound port 25 SMTP connections purporting to represent your domain from arbitary, not-preplanned IP addresses at will.

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. Yes, I understand there's an argument that it's "not legitimate", but it was long established practice and it broke. And it broke in exactly the ways that people knew SPF would break before they implemented it.
As I said, I can't help thinking that the big players that jumped in with this first, considered such breakage as "a good thing" - why on earth should Fred be allowed to put fred@??? on his website when he should be putting fred1234987234978@??? on there instead.

> What I know is that all legitimate linuxmafia.com mail originates from
> my MTA's static IPv4 address, and my declaring that in an SPF RR as the
> sole legitimate origin helps others definitively detect and reject
> forgeries. Therefore, I publish such an SPF RR, and am happy with the
> results.
>
> You say that for some reason you cannot gain the same benefit?

I said no such thing - and now it is getting harder to assume misunderstanding.

>> In a small way, by implementing SPF yourself, you've added to the
>> support for something that broke existing LEGITIMATE mail activities.
>
> I doubt your premise that SPF 'breaks' anything

It breaks mail forwarding as already mentioned. It breaks mail list managers configured as they were mostly previously configured. There's little to argue there - it's even stated in the design description for SPF that these would be broken. For list servers, there is an argument that all of the workarounds have undesirable characteristics.

> and find it highly suspicious that you don't support your assertion with anything even remotely resembling specifics.

Then you really didn't read properly then.

> However, additionally, your apparent inability or disinclination to publish information in your DNS saying 'All SMTP mail _not_ originating from IP addresses following this spec should be considered forgeries' (_which is the sum and substance_) utterly fails to be a reason why I ought not to, given that I can and have done so.

Again, please try reading what I wrote. I suspect you skimmed what I wrote and are responding to what you think I wrote - because you aren't responding to what I actually did write.
I have no technical argument why you should not do what you like with your own mail, but ...

>> So your approach has a hint of "I don't do that, so I don't care about
>> the people who do and now find it broken".
>
> Since nobody else's mail (other than my users') purports to originate
> from linuxmafia.com, I completely fail to see how my succesful
> deployment of a precise and accurate SPF RR adversely affects anyone
> else in the universe, let alone 'takes away their freedom'. You can try
> to show otherwise, if you want, but it's going to require some awfully
> compelling evidence, and I'm pretty certain you don't have any nor can
> acquire any.

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

As an analogy (though I admit a rather poor one), our general postal mail service (Royal Mail) have a service for redirecting mail. Useful, for example, when moving so you can have mail redirected when moving and you go through the painful process of letting the many people and organisations know about your new address. The new address does not have to be in the UK, it can be abroad - but if SPF existed in the postal mail world (and perhaps it should ?), it could stop someone (say) moving to France from receiving his forwarded mail. I rather think that people would be as intolerant of that as they would be if the postal carriers discarded postal mail like the carriers discard electronic mail.

Similarly, you also stopped Jim's ability to fully take part in some mailing lists until the people running the list manager software decided which bit of duct tape was least bad for their users.

> I'll be frank, too. Experience suggests that people making this
> argument are unwilling to come to terms with the modern reality that
> SMTP forgery is a huge problem and that circa-1995 policies of SMTP port
> 25 origination are a bad idea, and somehow think it's my job to
> contend better with reality.

I don't particularly disagree with that. In many ways it would have been better to have ditched SMTP back then and implemented something better - and yes there were proposals that were better (in particular, at least one of them shifted a large part of the cost of storage from receiver to sender). But as we've seen, that isn't going to happen any time soon, if ever. So I think we'll continue putting more duct tape on SMTP.

Like the old joke about a tourist asking a local for directions, only to get the answer that "I wouldn't start from here",

>> Hmm, didn't Devuan come into being partly due to someone pushing a
>> policy of not caring what he breaks for other people ? Sorry, that was
>> a bit below the belt but I hope it illustrates the issue.
>
> I wouldn't calling that hitting below the belt. I'd call it dribbling
> on your feet, since we're going for metaphorical imagery.

No, it really is a genuine comparison.
Consider this: a proposal (followed through with implementation), pushed though ignoring any objections, known to break existing setups/configurations (deliberately so), and accompanied with a "I/we don't care, it's your responsibility to fix/work around whatever I/we break" attitude. Am I describing SPF, or SystemD, or both ?

We "suggest" that people who blindly adopt SystemD without any thought about maintaining compatibility/freedom of choice for those choosing not to use it are "anti freedom of choice". As I said, it makes not a jot what us "little guys" do as the big guys made their decisions to break freedom of choice - but by adopting it you have tacitly approved of that behaviour - "because it works for me".

Simon