This is not strickly a Mac issue, but I hope there's folk here who can comment usefully.

SWMBO sent a mail to her brother, to his icloud email address. Unbeknownst to her, his icloud seems to be set up to forward the mail to gmail. gmail's reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address,
there are no issues.

I also had this while sending to another rellie who has her own domain, but which is set up to forward to gmail. Upon interrogation, her hubby confirmed about the auto-forwarding, saying that "I add a line to the dovecot rules
file. dovecot does the rest." Again, I can send direct to the destination
gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my hosting company about what SPF record they recommended, and then added their recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and forwarded by a third party, even though they can see the SPF record of the originating
sender.

Any suggestions for a way forward?

--
Tim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

TimS wrote:

This is not strickly a Mac issue, but I hope there's folk here who can comment
usefully.

SWMBO sent a mail to her brother, to his icloud email address. Unbeknownst to her, his icloud seems to be set up to forward the mail to gmail. gmail's reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the >> ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and
phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address, there are no issues.

I also had this while sending to another rellie who has her own domain, but which is set up to forward to gmail. Upon interrogation, her hubby confirmed about the auto-forwarding, saying that "I add a line to the dovecot rules file. dovecot does the rest." Again, I can send direct to the destination gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my hosting
company about what SPF record they recommended, and then added their recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and forwarded by a third party, even though they can see the SPF record of the originating sender.

Any suggestions for a way forward?

The third party that does the forwarding has to edit (rewrite) the SPF
record appropriately. Many ISPs that provide forwarding don't
understand how to do this. A specific example was https://easily.uk/ in
2018, which I think had something to do with the ownership of Easily
changing hands at the time. The only resolution was to move the hosting
away from Easily.

Some explanations of the detail here:

<https://www.pobox.help/hc/en-us/articles/360060504793-SPF-SRS-rewriting-and-how-it-affects-forwarding-email>

<https://community.spiceworks.com/topic/2211366-forwarding-by-recipient-email-server-breaking-spf-is-there-a-solution>

--
Graham J

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 20.04.23 um 12:25 schrieb TimS:

This is not strickly a Mac issue, but I hope there's folk here who can comment
usefully.

SWMBO sent a mail to her brother, to his icloud email address. Unbeknownst to her, his icloud seems to be set up to forward the mail to gmail. gmail's reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the >> ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and
phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address, there are no issues.

I also had this while sending to another rellie who has her own domain, but which is set up to forward to gmail. Upon interrogation, her hubby confirmed about the auto-forwarding, saying that "I add a line to the dovecot rules file. dovecot does the rest." Again, I can send direct to the destination gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my hosting
company about what SPF record they recommended, and then added their recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and forwarded by a third party, even though they can see the SPF record of the originating sender.

Any suggestions for a way forward?

Why should we discuss gmail issues in this *mac* group?

I would never use a gmail-address at all. Never ever!
In addition I filter all mails from gmail-servers unread to the waste
paper basket right on my servers already. That saves me about 3/4 of all
spam mails upfront. Google is not only evil they are also idiots.

--
Gutta cavat lapidem (Ovid)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/04/2023 11:56, Graham J wrote:

TimS wrote:

This is not strickly a Mac issue, but I hope there's folk here who can
comment
usefully.

SWMBO sent a mail to her brother, to his icloud email address.
Unbeknownst to
her, his icloud seems to be set up to forward the mail to gmail. gmail's
reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks
with the
ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and
phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address,
there are no issues.

I also had this while sending to another rellie who has her own
domain, but
which is set up to forward to gmail. Upon interrogation, her hubby
confirmed
about the auto-forwarding, saying that "I add a line to the dovecot rules
file. dovecot does the rest." Again, I can send direct to the destination
gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my
hosting
company about what SPF record they recommended, and then added their
recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and
forwarded by a
third party, even though they can see the SPF record of the originating
sender.

Any suggestions for a way forward?

The third party that does the forwarding has to edit (rewrite) the SPF
record appropriately.

With the caveat that I've not been involved with MTAs for about 10
years, I'm not sure that's correct.

SPF is checked on the receiving system's MTA:

* mail's arrived from an MTA at some.domain
* the actual mail claims to be from [email protected]
* does other.domain's DNS SPF record allow some.domain?

In other words SPF makes it harder to spoof mail froms, ie is it a red
flag that mail from "[email protected]" is coming from a google.com MTA?

In other words the owner of some.domain needs to update their own SPF
record in their own DNS.

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-04-20 11:40:49 +0000, Joerg Lorenz said:

Am 20.04.23 um 12:25 schrieb TimS:

This is not strickly a Mac issue, but I hope there's folk here who can comment
usefully.

SWMBO sent a mail to her brother, to his icloud email address. Unbeknownst to
her, his icloud seems to be set up to forward the mail to gmail. gmail's
reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the >>> ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and
phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address,
there are no issues.

I also had this while sending to another rellie who has her own domain, but >> which is set up to forward to gmail. Upon interrogation, her hubby confirmed >> about the auto-forwarding, saying that "I add a line to the dovecot rules
file. dovecot does the rest." Again, I can send direct to the destination
gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my hosting
company about what SPF record they recommended, and then added their
recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and forwarded by a
third party, even though they can see the SPF record of the originating
sender.

Any suggestions for a way forward?

Why should we discuss gmail issues in this *mac* group?

iCloud seems to be the/a relavent part of the issue.

<Apple-irrelevance snipped>

--
Cheers ... Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris Ridd wrote:

[snip]

The third party that does the forwarding has to edit (rewrite) the SPF
record appropriately.

With the caveat that I've not been involved with MTAs for about 10
years, I'm not sure that's correct.

SPF is checked on the receiving system's MTA:

* mail's arrived from an MTA at some.domain
* the actual mail claims to be from [email protected]
* does other.domain's DNS SPF record allow some.domain?

In other words SPF makes it harder to spoof mail froms, ie is it a red
flag that mail from "[email protected]" is coming from a google.com MTA?

In other words the owner of some.domain needs to update their own SPF
record in their own DNS.

Er, no.

Better explanation here:

<https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme>

It is some.domain that did the forwarding. The originator of the
message - [email protected] - would have to know that some.domain would
forward his message, and would have had to prepare his SPF record in
advance to allow for forwarding. This is obviously not impossible, but
the sender would have to identify the IP address (perhaps several) of
the MTA used by some.domain. So it could only be regarded as an
emergency work-around.

However, the user of some.domain has chosen to forward emails to his
gmail account. Therefore the MTA at some.domain should rewrite the
message header to show that the forwarded mail from [email protected] is
being sent from some.domain - which should be an automatic process
invoked by setting up the forwarding.


--
Graham J

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/04/2023 11:25, TimS wrote:

This is not strickly a Mac issue, but I hope there's folk here who can comment
usefully.

SWMBO sent a mail to her brother, to his icloud email address. Unbeknownst to her, his icloud seems to be set up to forward the mail to gmail. gmail's reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the >> ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and
phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address, there are no issues.

I also had this while sending to another rellie who has her own domain, but which is set up to forward to gmail. Upon interrogation, her hubby confirmed about the auto-forwarding, saying that "I add a line to the dovecot rules file. dovecot does the rest." Again, I can send direct to the destination gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my hosting
company about what SPF record they recommended, and then added their recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and forwarded by a third party, even though they can see the SPF record of the originating sender.

Any suggestions for a way forward?

It should 'just work'. So I'd suggest:

1) Confirm with the brother that he is intentionally forwarding iCloud
mail and that he did so by following these instructions: <https://support.apple.com/en-gb/guide/icloud/mm6b1a3960/icloud>

2) If so then raise a support call with Apple and complain that it
doesn't work.

3) Or give up and just email direct to his Gmail account?

--
Bruce Horrocks
Surrey, England

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20 Apr 2023 at 17:24:18 BST, "Bruce Horrocks" <[email protected]> wrote:

On 20/04/2023 11:25, TimS wrote:

This is not strickly a Mac issue, but I hope there's folk here who can comment
usefully.

SWMBO sent a mail to her brother, to his icloud email address. Unbeknownst to
her, his icloud seems to be set up to forward the mail to gmail. gmail's
reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the >>> ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and
phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address,
there are no issues.

I also had this while sending to another rellie who has her own domain, but >> which is set up to forward to gmail. Upon interrogation, her hubby confirmed >> about the auto-forwarding, saying that "I add a line to the dovecot rules
file. dovecot does the rest." Again, I can send direct to the destination
gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my hosting
company about what SPF record they recommended, and then added their
recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and forwarded by a
third party, even though they can see the SPF record of the originating
sender.

Any suggestions for a way forward?

It should 'just work'. So I'd suggest:

1) Confirm with the brother that he is intentionally forwarding iCloud
mail and that he did so by following these instructions: <https://support.apple.com/en-gb/guide/icloud/mm6b1a3960/icloud>

2) If so then raise a support call with Apple and complain that it
doesn't work.

3) Or give up and just email direct to his Gmail account?

Thanks to all for various replies. There's a number of things to say, here.

1) Evidently I'm not the first to come up against this. This has all come up
as fallout from John Lewis Broadband giving up, and that while I can move to PlusNet most easily, they're giving up on email too. So via my hosting
provider I grabbed a domain and started allocating email addresses. What concerned me a bit about this was fear that I'd find that the big email providers such as hotmail, gmail, were in effect squeezing everyone else out (such as JLB, Plusnet) by insisting on all sorts of restrictions in the name
of security and reducing spam/phishing.

2) No ordinary end-user is going to have the slightest clue about any of this, or what to do. My BiL probably won't, although he could moan to Apple about iCloud (I can check with him about how he set up forwarding).

3) Niece's hubby may be more up to speed but whether he can get the MAIL FROM re-written (or re-written correctly) is another matter.

--
Tim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20 Apr 2023 at 17:23:17 BST, "Graham J" <[email protected]> wrote:

Chris Ridd wrote:

[snip]

The third party that does the forwarding has to edit (rewrite) the SPF
record appropriately.

With the caveat that I've not been involved with MTAs for about 10
years, I'm not sure that's correct.

SPF is checked on the receiving system's MTA:

* mail's arrived from an MTA at some.domain
* the actual mail claims to be from [email protected]
* does other.domain's DNS SPF record allow some.domain?

In other words SPF makes it harder to spoof mail froms, ie is it a red
flag that mail from "[email protected]" is coming from a google.com MTA?

In other words the owner of some.domain needs to update their own SPF
record in their own DNS.

Er, no.

Better explanation here:

<https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme>

It is some.domain that did the forwarding. The originator of the
message - [email protected] - would have to know that some.domain would forward his message, and would have had to prepare his SPF record in
advance to allow for forwarding. This is obviously not impossible, but
the sender would have to identify the IP address (perhaps several) of
the MTA used by some.domain. So it could only be regarded as an
emergency work-around.

However, the user of some.domain has chosen to forward emails to his
gmail account. Therefore the MTA at some.domain should rewrite the
message header to show that the forwarded mail from [email protected] is
being sent from some.domain - which should be an automatic process
invoked by setting up the forwarding.

That makes sense.

--
Tim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 20.04.23 um 14:38 schrieb Mark:

On 2023-04-20 11:40:49 +0000, Joerg Lorenz said:

Am 20.04.23 um 12:25 schrieb TimS:

This is not strickly a Mac issue, but I hope there's folk here who can comment
usefully.

SWMBO sent a mail to her brother, to his icloud email address. Unbeknownst to
her, his icloud seems to be set up to forward the mail to gmail. gmail's >>> reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the
ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and >>>> phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address, >>> there are no issues.

I also had this while sending to another rellie who has her own domain, but >>> which is set up to forward to gmail. Upon interrogation, her hubby confirmed
about the auto-forwarding, saying that "I add a line to the dovecot rules >>> file. dovecot does the rest." Again, I can send direct to the destination >>> gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my hosting
company about what SPF record they recommended, and then added their
recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and forwarded by a
third party, even though they can see the SPF record of the originating
sender.

Any suggestions for a way forward?

Why should we discuss gmail issues in this *mac* group?

iCloud seems to be the/a relavent part of the issue.

iCloud does what it is meant to do in this scenario. Gmail has an/the issue.

--
De gustibus non est disputandum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris Ridd wrote:

[snip]

.

Nod. But the thing they're *not* doing is changing the SPF record as you indicated in your original post:

The third party that does the forwarding has to edit (rewrite) the SPF
record appropriately

They're (just) rewriting the envelope address.

Sorry, I was wrong. You are correct.


--
Graham J

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/04/2023 17:23, Graham J wrote:

Chris Ridd wrote:

[snip]

The third party that does the forwarding has to edit (rewrite) the
SPF record appropriately.

With the caveat that I've not been involved with MTAs for about 10
years, I'm not sure that's correct.

SPF is checked on the receiving system's MTA:

* mail's arrived from an MTA at some.domain
* the actual mail claims to be from [email protected]
* does other.domain's DNS SPF record allow some.domain?

In other words SPF makes it harder to spoof mail froms, ie is it a red
flag that mail from "[email protected]" is coming from a google.com MTA?

In other words the owner of some.domain needs to update their own SPF
record in their own DNS.

Er, no.

Better explanation here:

<https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme>

Thanks for the link, it clarifies you're actually talking about SRS
instead, which seems kind of interesting. (In an SMTP-as-train-wreck
kind of way.)

It is some.domain that did the forwarding.  The originator of the
message - [email protected] - would have to know that some.domain would forward his message, and would have had to prepare his SPF record in
advance to allow for forwarding.  This is obviously not impossible, but
the sender would have to identify the IP address (perhaps several) of
the MTA used by some.domain.  So it could only be regarded as an
emergency work-around.

However, the user of some.domain has chosen to forward emails to his
gmail account.  Therefore the MTA at some.domain should rewrite the
message header to show that the forwarded mail from [email protected] is
being sent from some.domain - which should be an automatic process
invoked by setting up the forwarding.

Nod. But the thing they're *not* doing is changing the SPF record as you indicated in your original post:

The third party that does the forwarding has to edit (rewrite) the SPF record appropriately

They're (just) rewriting the envelope address.

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Joerg Lorenz wrote:

[snip]

iCloud seems to be the/a relavent part of the issue.

iCloud does what it is meant to do in this scenario. Gmail has an/the issue.

No, Gmail is doing the right thing - it is protecting its users from
potential spam.

The ISP doing the forwarding is not behaving properly, see:

<https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme>

The explanation covers the correct receipt of bounce messages, which is
not the issue here. But the SRS can also be used to ensure forwarded
messages are not rejected by a downstream SPF check.

<https://en.wikipedia.org/wiki/Sender_Policy_Framework>

... gives more general information - see specifically the section headed
"FAIL and forwarding".


--
Graham J

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 20.04.23 um 23:17 schrieb Graham J:

Joerg Lorenz wrote:

[snip]

iCloud seems to be the/a relavent part of the issue.

iCloud does what it is meant to do in this scenario. Gmail has an/the issue.

No, Gmail is doing the right thing - it is protecting its users from potential spam.

This is simply your personal opinion. Apple sends the mail and gmail
does not accept the mail for obscure reasons and pretending spam-protection.



--
De gustibus non est disputandum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Liz Tuddenham wrote:

TimS <[email protected]> wrote:

[...]

1) Evidently I'm not the first to come up against this.

I've been battling against this, or something like it, for many months. Suddenly i found all my e-mails to gmail accounts were being bounced;
the only way I can get them through is to send them from an old Plusnet account or redirect them from an Easily account.

We've discussed this before. We would need to see a selection of bounce messages to understand your current problem, but in the past it was
evident that you could not communicate your wishes to your ISP (a
one-man-band, I think), consequently your mail server is not set up
correctly.

Sending via Plusnet would be expected to work given that they set up
their mail service properly.

Redirecting from an Easily account does not make sense - it would be the
recipient who has an account with Easily who would redirect their own incoming emails to gmail. I suspect the redirection problem I saw with
Easily in 2018 has since been resolved.

If I can do this, so can spammers, so where is the 'security' in that?
It seems much more likely to be a move to force people into updates or changes they don't really need.

SPF and DKIM protection are just two of many anti-spam mechanisms. They
help minimise mail which pretends to be from a trusted source. Mail
coming from other sources that you don't recognise will still get
through these checks, so you need other mechanisms to identify emails containing malware.

In general, updates do in part exist to correct historical errors of
design or implementation, so they are generally worth applying.

--
Graham J

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

TimS <[email protected]> wrote:

[...]

1) Evidently I'm not the first to come up against this.

I've been battling against this, or something like it, for many months. Suddenly i found all my e-mails to gmail accounts were being bounced;
the only way I can get them through is to send them from an old Plusnet
account or redirect them from an Easily account.

If I can do this, so can spammers, so where is the 'security' in that?
It seems much more likely to be a move to force people into updates or
changes they don't really need.

--
~ Liz Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 21.04.23 um 11:01 schrieb Graham J:

Liz Tuddenham wrote:

TimS <[email protected]> wrote:

[...]

1) Evidently I'm not the first to come up against this.

I've been battling against this, or something like it, for many months.
Suddenly i found all my e-mails to gmail accounts were being bounced;
the only way I can get them through is to send them from an old Plusnet
account or redirect them from an Easily account.

We've discussed this before. We would need to see a selection of bounce messages to understand your current problem, but in the past it was
evident that you could not communicate your wishes to your ISP (a one-man-band, I think), consequently your mail server is not set up correctly.

Sending via Plusnet would be expected to work given that they set up
their mail service properly.

The murderer is the victim?
No other service acts up like Google without informing the users. Spam
and security at Google is at the lowest possible level and inconsistent.

--
De gustibus non est disputandum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 21.04.23 um 10:14 schrieb Liz Tuddenham:

TimS <[email protected]> wrote:

[...]

1) Evidently I'm not the first to come up against this.

I've been battling against this, or something like it, for many months. Suddenly i found all my e-mails to gmail accounts were being bounced;
the only way I can get them through is to send them from an old Plusnet account or redirect them from an Easily account.

If I can do this, so can spammers, so where is the 'security' in that?
It seems much more likely to be a move to force people into updates or changes they don't really need.

Google is evil and they are idiots.

--
De gustibus non est disputandum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/04/2023 11:25, TimS wrote:

This is not strickly a Mac issue, but I hope there's folk here who can comment
usefully.

SWMBO sent a mail to her brother, to his icloud email address. Unbeknownst to her, his icloud seems to be set up to forward the mail to gmail. gmail's reaction to this was:

The MAIL FROM domain [example.com] has an SPF record with a
hard 550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the >> ip: 550-5.7.26 [17.58.63.172]. To best protect our users from spam and
phishing, 550-5.7.26 the message has been blocked. Please visit ...

and to reject the mail. If she sends directly to her bro's gmail address, there are no issues.

I also had this while sending to another rellie who has her own domain, but which is set up to forward to gmail. Upon interrogation, her hubby confirmed about the auto-forwarding, saying that "I add a line to the dovecot rules file. dovecot does the rest." Again, I can send direct to the destination gmail address with no trouble.

Last year my mail to gmail destinations started failing, so I asked my hosting
company about what SPF record they recommended, and then added their recommended SPF (TEXT) record, which fixed that.

So mail sent direct is OK, but gmail refuses mail sent via and forwarded by a third party, even though they can see the SPF record of the originating sender.

Any suggestions for a way forward?

I think that there are two things wrong here.

Google are using DMARC to look for either an SPF pass or DKIM pass
before allowing an incoming mail.

You have specified SPF with a hard fail, so this means that mails from
you will only be valid if sent directly and can never be automatically forwarded (this is 'safest', so why your hosting company recommended it,
but quite restrictive).

If you didn't have such a strict SPF policy then you could make
forwarding work by also using DKIM, so then your original message would
get a DKIM pass to offset the SPF soft fail which always results from
automatic forwarding.

Nicest description that I've found is <https://powerdmarc.com/email-forwarding-dmarc/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/04/2023 10:22, Joerg Lorenz wrote:

Am 21.04.23 um 10:14 schrieb Liz Tuddenham:

TimS <[email protected]> wrote:

[...]

1) Evidently I'm not the first to come up against this.

I've been battling against this, or something like it, for many months.
Suddenly i found all my e-mails to gmail accounts were being bounced;
the only way I can get them through is to send them from an old Plusnet
account or redirect them from an Easily account.

If I can do this, so can spammers, so where is the 'security' in that?
It seems much more likely to be a move to force people into updates or
changes they don't really need.

Google is evil and they are idiots.

The first accurate description that I've seen of Google: Evil Idiots!

I like it, bonus points that man.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21 Apr 2023 at 11:42:22 BST, "David Sankey" <[email protected]>
wrote:

On 20/04/2023 11:25, TimS wrote:

[snip]

Any suggestions for a way forward?

I think that there are two things wrong here.

Google are using DMARC to look for either an SPF pass or DKIM pass
before allowing an incoming mail.

You have specified SPF with a hard fail, so this means that mails from
you will only be valid if sent directly and can never be automatically forwarded (this is 'safest', so why your hosting company recommended it,
but quite restrictive).

If you didn't have such a strict SPF policy then you could make
forwarding work by also using DKIM, so then your original message would
get a DKIM pass to offset the SPF soft fail which always results from automatic forwarding.

Sounds like you are suggesting that I replace -ALL with ~ALL in my SPF record. That is something I am considering. The forwarding aspect is not, and never could be, under my control.

--
Tim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20 Apr 2023 at 21:17:38 BST, "Chris Ridd" <[email protected]> wrote:

Thanks for the link, it clarifies you're actually talking about SRS
instead, which seems kind of interesting. (In an SMTP-as-train-wreck
kind of way.)

Joy! I've been out of the email wrangling business so long I didn't even
know of SRS :)

Cheers - Jaimie
--
If you are not paying for it, you're not the customer; you're the product being sold.
-- blue_beetle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Joerg Lorenz <[email protected]> wrote:

Am 21.04.23 um 11:01 schrieb Graham J:

Liz Tuddenham wrote:

TimS <[email protected]> wrote:

[...]

1) Evidently I'm not the first to come up against this.

I've been battling against this, or something like it, for many months.
Suddenly i found all my e-mails to gmail accounts were being bounced;
the only way I can get them through is to send them from an old Plusnet
account or redirect them from an Easily account.

We've discussed this before. We would need to see a selection of bounce messages to understand your current problem, but in the past it was
evident that you could not communicate your wishes to your ISP (a one-man-band, I think), consequently your mail server is not set up correctly.

Sending via Plusnet would be expected to work given that they set up
their mail service properly.

The murderer is the victim?

I completely agree. Google is unilaterally trying to enforce something
that is supposed to be optiional. That is not the fault of the other
ISPs, who are sending out e-mails which conform to internationally
agreed standards and havng them arbitrarily rejected.


--
~ Liz Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/04/2023 14:03, Liz Tuddenham wrote:

Joerg Lorenz <[email protected]> wrote:

Am 21.04.23 um 11:01 schrieb Graham J:

Liz Tuddenham wrote:

TimS <[email protected]> wrote:

[...]

1) Evidently I'm not the first to come up against this.

I've been battling against this, or something like it, for many months. >>>> Suddenly i found all my e-mails to gmail accounts were being bounced;
the only way I can get them through is to send them from an old Plusnet >>>> account or redirect them from an Easily account.

We've discussed this before. We would need to see a selection of bounce >>> messages to understand your current problem, but in the past it was
evident that you could not communicate your wishes to your ISP (a
one-man-band, I think), consequently your mail server is not set up
correctly.

Sending via Plusnet would be expected to work given that they set up
their mail service properly.

The murderer is the victim?

I completely agree. Google is unilaterally trying to enforce something
that is supposed to be optiional. That is not the fault of the other
ISPs, who are sending out e-mails which conform to internationally
agreed standards and havng them arbitrarily rejected.

Hello Liz

I've been reading your posts and the answers to them.

I've wondered if you are familiar with Proton.

I've used it and it works well, but I've not paid any money to do so.

https://proton.me/

HTH

--
David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-04-21 13:08:51 +0000, Alan B said:

Liz Tuddenham <[email protected]d> wrote:
properly.

Google is unilaterally trying to enforce something
that is supposed to be optiional. That is not the fault of the other
ISPs, who are sending out e-mails which conform to internationally
agreed standards and havng them arbitrarily rejected.

I’m just glad gmail is not my primary email account then!

You'd hope they wouldn't be doing anything unusual (IRT email) given
the size of their user base - including providing the back end to
education institutions, businesses and government bodies.
--
Cheers ... Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/04/2023 12:37, Jaimie Vandenbergh wrote:

On 20 Apr 2023 at 21:17:38 BST, "Chris Ridd" <[email protected]> wrote:

Thanks for the link, it clarifies you're actually talking about SRS
instead, which seems kind of interesting. (In an SMTP-as-train-wreck
kind of way.)

Joy! I've been out of the email wrangling business so long I didn't even
know of SRS :)

Indeed! I'm very happy to let some other poor bugger worry about this
sort of horrible stuff :-)

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)