SPF failure messages

[Adam H. Kerman]

This isn't an alpine issue, but perhaps Eduardo might provide some
expert guidance.

For business purposes, I send email through a variety of domains, each
specific to a business. I have set up IMAP and roles within alpine to
facilitate this.

I don't control all the zone files related to domains I send through.
One domain gives me particular grief with respect to Mail servers
enforcing SPF.

Well, SPF isn't set up the way we use it and the host I use alpine
on is affected by the -all restriction. I have no idea how it was set up
but I suspect the same highly-restrictive policy was added to every
domain at this registrar. It also affects emails sent by the guy who
does have access to the zone file.

I'm stuck because he's not interested in learning about SPF.

I have to use the (barf) Web interface to send messages.

I wonder: Am I receiving all SPF failure messages? Does the recipient
refusing the connection per our own SPF policies take the position that
I'm a forger and there's no way to reach the forger to point out the SPF
restriction, and not send the failure notice?

[J.O. Aho]

On 27/01/2023 22:43, Adam H. Kerman wrote:

> I'm stuck because he's not interested in learning about SPF.

Not much to learn there IMHO
https://dmarcian.com/spf-syntax-table/

I guess you can do a "dig -t TXT" for the domain and then add what you
need to have added there and then suggest the new SPF record to your
zone admin.

> I have to use the (barf) Web interface to send messages.

Usually the mail provider do provide smtp and the outgoing mail from the
web interface will be relayed to that smtp server or else the same
machine is included in the SPF record.

> I wonder: Am I receiving all SPF failure messages?

Not all sends, but say google does send a report once a day to the rua
(you also have ruf, but never used that one) mentioned in the DMARC record.

> Does the recipient
> refusing the connection per our own SPF policies take the position that
> I'm a forger and there's no way to reach the forger to point out the SPF
> restriction, and not send the failure notice?

SPF record together with DMARC record are guidelines for the receiving
mail server, for example I use -all on my SPF and p=reject on my DMARC,
but in the end it's not me who decide how the receiving server handles
things, that is a discussion with the administrator of that system.


--
//Aho

[John Levine]

It appears that Adam H. Kerman <a...@chinet.com> said:
>I wonder: Am I receiving all SPF failure messages?

What do you mean by SPF failure messages? SPF is an authentication
scheme, it doesn't send anything. If you mean do all of the SMTP
rejections say "we hate your SPF", nope. Also keep in mind that few
non-hobbyist mail systems reject solely because of SPF failure.

Or do you mean DMARC, where failures do cause a lot of mail rejections?

R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[Adam H. Kerman]

John Levine <jo...@taugh.com> wrote:
>It appears that Adam H. Kerman <a...@chinet.com> said:

>>I wonder: Am I receiving all SPF failure messages?

>What do you mean by SPF failure messages? SPF is an authentication
>scheme, it doesn't send anything. If you mean do all of the SMTP
>rejections say "we hate your SPF", nope. Also keep in mind that few
>non-hobbyist mail systems reject solely because of SPF failure.

Perhaps if you'd read the rest of what I'd written, or even the entire
paragraph, instead of just the one sentence, the meaning would have been
entirely clear to you from context.

The domain has an SPF policy. I don't have a shell account on the host
of that domain. I do have various email addresses. Using alpine from my
own host, I am in violation of the SPF policy. If the network receiving
email enforces the domain's SPF policy, it won't receive my messages.

If I'm being treated like a forger, I'm questioning whether the site
necessarily sends a notice stating that the message was rejected, given
that it's going to assume ENVELOPE-FROM was forged.

>Or do you mean DMARC, where failures do cause a lot of mail rejections?

I don't require a translator, John.

[Carlos E.R.]

On 2023-01-28 05:36, Adam H. Kerman wrote:
> John Levine <jo...@taugh.com> wrote:
>> It appears that Adam H. Kerman <a...@chinet.com> said:
>
>>> I wonder: Am I receiving all SPF failure messages?
>
>> What do you mean by SPF failure messages? SPF is an authentication
>> scheme, it doesn't send anything. If you mean do all of the SMTP
>> rejections say "we hate your SPF", nope. Also keep in mind that few
>> non-hobbyist mail systems reject solely because of SPF failure.
>
> Perhaps if you'd read the rest of what I'd written, or even the entire
> paragraph, instead of just the one sentence, the meaning would have been
> entirely clear to you from context.
>
> The domain has an SPF policy. I don't have a shell account on the host
> of that domain. I do have various email addresses. Using alpine from my
> own host, I am in violation of the SPF policy. If the network receiving
> email enforces the domain's SPF policy, it won't receive my messages.

Well, you have to use the smtp server that is authorized to send email
for the domain, not yours.

>
> If I'm being treated like a forger, I'm questioning whether the site
> necessarily sends a notice stating that the message was rejected, given
> that it's going to assume ENVELOPE-FROM was forged.

If by message you mean an email, no. The smtp server will reply with a
more or less helpful "text", that the smtp server that is talking on
your behalf will log in the mail log file. It is up to the sending smtp
server to send you a rejection email, or not.


--
Cheers, Carlos.

[Adam H. Kerman]

Carlos E.R. <robin_...@es.invalid> wrote:
>On 2023-01-28 05:36, Adam H. Kerman wrote:
>>John Levine <jo...@taugh.com> wrote:
>>>It appears that Adam H. Kerman <a...@chinet.com> said:

>>>>I wonder: Am I receiving all SPF failure messages?

>>>What do you mean by SPF failure messages? SPF is an authentication
>>>scheme, it doesn't send anything. If you mean do all of the SMTP
>>>rejections say "we hate your SPF", nope. Also keep in mind that few
>>>non-hobbyist mail systems reject solely because of SPF failure.

>>Perhaps if you'd read the rest of what I'd written, or even the entire
>>paragraph, instead of just the one sentence, the meaning would have been
>>entirely clear to you from context.

>>The domain has an SPF policy. I don't have a shell account on the host
>>of that domain. I do have various email addresses. Using alpine from my
>>own host, I am in violation of the SPF policy. If the network receiving
>>email enforces the domain's SPF policy, it won't receive my messages.

>Well, you have to use the smtp server that is authorized to send email
>for the domain, not yours.

This is irrelevant to the issue that I have raised. In fact, if you had
read the root article, I stated that I use roles, which is where SMTP is
set up.

>>If I'm being treated like a forger, I'm questioning whether the site
>>necessarily sends a notice stating that the message was rejected, given
>>that it's going to assume ENVELOPE-FROM was forged.

>If by message you mean an email, no.

Oh my gawd

What is it with inability to glean meaning from context? Yes, I've been
discussing email messages all along. That's what we discuss in this newsgroup.

>The smtp server will reply with a
>more or less helpful "text", that the smtp server that is talking on
>your behalf will log in the mail log file. It is up to the sending smtp
>server to send you a rejection email, or not.

Asking about common practice of sending such a message was the entire
point of this thread!

If the message is rejected, then I'm being treated like a forging
spammer per SPF policy. The receiving site would assume ENVELOPE-FROM
was forged, and for that reason, there's no reason to send any failure
notice to that address.

I don't have access to log files. I've already stated that I don't have
access to the DNS zone file, otherwise I'd fix SPF to reflect how we
actually send messages.

[Carlos E.R.]

On 2023-01-28 17:23, Adam H. Kerman wrote:
> Carlos E.R. <robin_...@es.invalid> wrote:
>> On 2023-01-28 05:36, Adam H. Kerman wrote:
>>> John Levine <jo...@taugh.com> wrote:
>>>> It appears that Adam H. Kerman <a...@chinet.com> said:
>
>>>>> I wonder: Am I receiving all SPF failure messages?
>
>>>> What do you mean by SPF failure messages? SPF is an authentication
>>>> scheme, it doesn't send anything. If you mean do all of the SMTP
>>>> rejections say "we hate your SPF", nope. Also keep in mind that few
>>>> non-hobbyist mail systems reject solely because of SPF failure.
>
>>> Perhaps if you'd read the rest of what I'd written, or even the entire
>>> paragraph, instead of just the one sentence, the meaning would have been
>>> entirely clear to you from context.
>
>>> The domain has an SPF policy. I don't have a shell account on the host
>>> of that domain. I do have various email addresses. Using alpine from my
>>> own host, I am in violation of the SPF policy. If the network receiving
>>> email enforces the domain's SPF policy, it won't receive my messages.
>
>> Well, you have to use the smtp server that is authorized to send email
>> for the domain, not yours.
>
> This is irrelevant to the issue that I have raised. In fact, if you had
> read the root article, I stated that I use roles, which is where SMTP is
> set up.

I know you are using roles.

>
>>> If I'm being treated like a forger, I'm questioning whether the site
>>> necessarily sends a notice stating that the message was rejected, given
>>> that it's going to assume ENVELOPE-FROM was forged.
>
>> If by message you mean an email, no.
>
> Oh my gawd
>
> What is it with inability to glean meaning from context? Yes, I've been
> discussing email messages all along. That's what we discuss in this newsgroup.
>
>> The smtp server will reply with a
>> more or less helpful "text", that the smtp server that is talking on
>> your behalf will log in the mail log file. It is up to the sending smtp
>> server to send you a rejection email, or not.
>
> Asking about common practice of sending such a message was the entire
> point of this thread!
>
> If the message is rejected, then I'm being treated like a forging
> spammer per SPF policy. The receiving site would assume ENVELOPE-FROM
> was forged, and for that reason, there's no reason to send any failure
> notice to that address.
>
> I don't have access to log files. I've already stated that I don't have
> access to the DNS zone file, otherwise I'd fix SPF to reflect how we
> actually send messages.

And I am telling you that the SMTP server that refuses your email will
NEVER send you an email with the refusal reason. That is not how it works.

It is your own smtp server (usually at your provider or at your domain)
who is responsible to send you an email with the rejection.


--
Cheers, Carlos.

[Adam H. Kerman]

Carlos E.R. <robin_...@es.invalid> wrote:
>On 2023-01-28 17:23, Adam H. Kerman wrote:
>>Carlos E.R. <robin_...@es.invalid> wrote:
>>>On 2023-01-28 05:36, Adam H. Kerman wrote:
>>>>John Levine <jo...@taugh.com> wrote:
>>>>>It appears that Adam H. Kerman <a...@chinet.com> said:

>>>>>>I wonder: Am I receiving all SPF failure messages?

>>>>>What do you mean by SPF failure messages? SPF is an authentication
>>>>>scheme, it doesn't send anything. If you mean do all of the SMTP
>>>>>rejections say "we hate your SPF", nope. Also keep in mind that few
>>>>>non-hobbyist mail systems reject solely because of SPF failure.

>>>>Perhaps if you'd read the rest of what I'd written, or even the entire
>>>>paragraph, instead of just the one sentence, the meaning would have been
>>>>entirely clear to you from context.

>>>>The domain has an SPF policy. I don't have a shell account on the host
>>>>of that domain. I do have various email addresses. Using alpine from my
>>>>own host, I am in violation of the SPF policy. If the network receiving
>>>>email enforces the domain's SPF policy, it won't receive my messages.

>>>Well, you have to use the smtp server that is authorized to send email
>>>for the domain, not yours.

>>This is irrelevant to the issue that I have raised. In fact, if you had
>>read the root article, I stated that I use roles, which is where SMTP is
>>set up.

>I know you are using roles.

Then what could have possibly been the point of the comment that I have
to use the SMTP server authorized to send email for that domain given that
the user creates a role to tell alpine which SMTP server is authorized to
send email for that domain?

That's irrelevant to the SPF policy.

I have a shell account on host1.example.net. I use alpine from the
shell. I send messages from us...@example.com. In a role, when I am
sending messages from us...@example.com, alpine is instructed to use the
SMTP server smtp.example.com, the SMTP server that's authorized to send
mail for the domain example.com.

The SPF policy violation is that my email client is on a host that is
in an unlisted foreign network.

Ok. Thank you. That was helpful. Reviewing the failure notices, none of
them came from the domain that refused the connection. None of them came
from the SMTP server for the domain in question. Instead they came from
the mail server in my own network.

So that truly suggests I'm not missing any failure notices, which is
what I needed to know.

[J.O. Aho]

On 28/01/2023 17:23, Adam H. Kerman wrote:

> If the message is rejected, then I'm being treated like a forging
> spammer per SPF policy. The receiving site would assume ENVELOPE-FROM
> was forged, and for that reason, there's no reason to send any failure
> notice to that address.

It's not the receiving end that send you the mail notifications, it's
the sending end that does that.

> I don't have access to log files. I've already stated that I don't have
> access to the DNS zone file, otherwise I'd fix SPF to reflect how we
> actually send messages.

It's a big difference between zone files and a servers log files, there
are many server administrators who don't have access to the zone file.

I do suggest you use the smtp server that the SPF record defines as the
one allowed, if you do not have access to use it, then ask if it would
be possible get an account that can send from that smtp server.
You will need to have different outgoing smtp for each domain.

--

//Aho

[Adam H. Kerman]

J.O. Aho <us...@example.net> wrote:

>. . .

>I do suggest you use the smtp server that the SPF record defines as the
>one allowed, if you do not have access to use it, then ask if it would
>be possible get an account that can send from that smtp server.
>You will need to have different outgoing smtp for each domain.

As I have explained since the root article in this thread, I am using
the SMTP server for the domain in question. I use a different SMTP
server for each domain I send messages from. The SMTP server to use
is named in the role. None of this has anything to do with SPF.

No, I am not going to get a shell account on a host that's on the
network in question just so I can use alpine without violating the SPF
restriction. That doesn't meet my needs.

[J.O. Aho]

On 28/01/2023 21:13, Adam H. Kerman wrote:
> J.O. Aho <us...@example.net> wrote:
>
>> . . .
>
>> I do suggest you use the smtp server that the SPF record defines as the
>> one allowed, if you do not have access to use it, then ask if it would
>> be possible get an account that can send from that smtp server.
>> You will need to have different outgoing smtp for each domain.
>
> As I have explained since the root article in this thread, I am using
> the SMTP server for the domain in question. I use a different SMTP
> server for each domain I send messages from. The SMTP server to use
> is named in the role. None of this has anything to do with SPF.

I did not see any mentioning that you hade configured domain specific
smtp servers, all I really saw was that you barfed on having to use
webmail to send.

If you are using the correct SMTP server for sending the mail, then SPF
will not affect you, on the other hand DMARC could affect you,
specially if the DKIM isn't properly configured on the sending SMTP or
the public key missing in the DNS domainkey record mentioned in the DKIM
signing.
Still the sending stmp server that will notify about mail rejected.

> No, I am not going to get a shell account on a host that's on the
> network in question just so I can use alpine without violating the SPF
> restriction. That doesn't meet my needs.

No one was talking about a shell account, mail account (the one you
have as sending email address) on the authorized smtp server.

--

//Aho

[Carlos E.R.]

No, that is not a violation.

For example, I use Alpine, with a role to send emails with
some...@telefonica.net. Alpine I have configured to pass the email to
my own postfix, which is on a dynamic address and thus not authorized by
Telefónica, obviously.

I pass the email over to smtp.telefonica.net. My postfix authenticates
as customer using a login and password, and then the smtp server sends
email to the destination. They are authorized.

cer@Telcontar:~> host -t TXT telefonica.net
telefonica.net descriptive text "zgk3kx4tm8vnwt6wmg09fym0s51slgt0"
telefonica.net descriptive text "0fgjbcgt3yv41fk9ghygq35k8v133xfp"
telefonica.net descriptive text "v=spf1 mx ptr:mailhost.telefonica.net
mx:dominios.telefonica.net include:spf2.telefonica.net
+a:spf.telefonica.net ip4:213.4.128.121 ip4:213.4.129.0/24
ip4:213.4.134.0/24 ip4:213.4.138.0/24 ip4:213.4.140.7 ip4:213.4.149.0/24
ip4:80.58.60.0/24" " include:spf.e.telefonica.net -all"
cer@Telcontar:~>


The IP of the machine I use to run alpine is irrelevant. It is logged,
but that is not the machine that has to be verified. If I ssh to this
machine from yet another to run Alpine, that is also irrelevant (and not
logged).

Good :-)

--
Cheers, Carlos.

[Adam H. Kerman]

J.O. Aho <us...@example.net> wrote:
>On 28/01/2023 21:13, Adam H. Kerman wrote:
>>J.O. Aho <us...@example.net> wrote:

>>>. . .

>>>I do suggest you use the smtp server that the SPF record defines as the
>>>one allowed, if you do not have access to use it, then ask if it would
>>>be possible get an account that can send from that smtp server.
>>>You will need to have different outgoing smtp for each domain.

>>As I have explained since the root article in this thread, I am using
>>the SMTP server for the domain in question. I use a different SMTP
>>server for each domain I send messages from. The SMTP server to use
>>is named in the role. None of this has anything to do with SPF.

>I did not see any mentioning that you hade configured domain specific

>smtp servers, . . .

For business purposes, I send email through a variety of domains,
each specific to a business. I have set up IMAP and roles within
alpine to facilitate this.

I wrote this in the root article. I repeated it in several followups.
This is irrelevant to the problem I'm having.

>If you are using the correct SMTP server for sending the mail, then SPF

>will not affect you, . . .

There's no point in discussing this with you since you refuse to believe
what I've literally written. Other people told me what I needed to know.

[Adam H. Kerman]

Carlos E.R. <robin_...@es.invalid> wrote:
>On 2023-01-28 20:57, Adam H. Kerman wrote:

>>. . .

>>That's irrelevant to the SPF policy.

>>I have a shell account on host1.example.net. I use alpine from the
>>shell. I send messages from us...@example.com. In a role, when I am
>>sending messages from us...@example.com, alpine is instructed to use the
>>SMTP server smtp.example.com, the SMTP server that's authorized to send
>>mail for the domain example.com.

>>The SPF policy violation is that my email client is on a host that is
>>in an unlisted foreign network.

>No, that is not a violation.

As I've explained, the SPF policy has an -all restriction and rejects
the IP address of my host. It's literally in all the failure notices
I've received.

I cannot explain why your -all restriction isn't tripping you up.

>. . .

[John Levine]

According to Adam H. Kerman <a...@chinet.com>:

>As I've explained, the SPF policy has an -all restriction and rejects
>the IP address of my host. It's literally in all the failure notices
>I've received.

I believe it, but I am also guessing that those are from very small systems.
As I said a few messages ago, serious mail systems ignore -all because there
are so many false positives. The place where -all causes trouble in practice
is with DMARC policies which depend on SPF alignment.

>I cannot explain why your -all restriction isn't tripping you up.

See above.

In any event, if your mail provider insists on a stupid configuration,
either you live with it, or you take your business elsewhere.

[J.O. Aho]

On 28/01/2023 22:39, Adam H. Kerman wrote:
> J.O. Aho <us...@example.net> wrote:
>> On 28/01/2023 21:13, Adam H. Kerman wrote:
>>> J.O. Aho <us...@example.net> wrote:
>
>>>> . . .
>
>>>> I do suggest you use the smtp server that the SPF record defines as the
>>>> one allowed, if you do not have access to use it, then ask if it would
>>>> be possible get an account that can send from that smtp server.
>>>> You will need to have different outgoing smtp for each domain.
>
>>> As I have explained since the root article in this thread, I am using
>>> the SMTP server for the domain in question. I use a different SMTP
>>> server for each domain I send messages from. The SMTP server to use
>>> is named in the role. None of this has anything to do with SPF.
>
>> I did not see any mentioning that you hade configured domain specific
>> smtp servers, . . .
>
> For business purposes, I send email through a variety of domains,
> each specific to a business. I have set up IMAP and roles within
> alpine to facilitate this.
>
> I wrote this in the root article. I repeated it in several followups.
> This is irrelevant to the problem I'm having.

Still do not specify anything about your smtp setup, so if you have
issues due of SPF then your error is in the smtp-server in your ~/.pinerc

>> If you are using the correct SMTP server for sending the mail, then SPF
>> will not affect you, . . .
>
> There's no point in discussing this with you since you refuse to believe
> what I've literally written.

You are to vague and lack of example, like how the domains SPF record
look like.
if it's "v=spf1 -all" then no matter what smtp server you try to use, it
will not be accepted.

> Other people told me what I needed to know.

I can see you don't really trust them either... so your loss.

--

//Aho

[Carlos E.R.]

Well, without actually seeing the actual data, I can only guess that
someone is not doing things properly, or someone not interpreting things
properly.

>
> I cannot explain why your -all restriction isn't tripping you up.

Because I am doing it correctly :-)


I just sent an email to myself, from one account at telefonica to
another at gmail.

This is alpine talking with my postfix server:


Received: from localhost (localhost [127.0.0.1])
by Telcontar.valinor (Postfix) with ESMTP id AC3B4320A51
for <...@gmail.com>; Sun, 29 Jan 2023 00:48:59 +0100 (CET)



This is my ISP getting the email (with some line wrapping):


Received: from Telcontar.valinor (Y.red-X-151-90.dynamicip.rima-tde.net
[79.151.X.Y])
(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
(Authenticated sender: ...@telefonica.net)
by relayout04.e.movistar.es (Postfix) with ESMTPSA id 4P4B3w0pPWz17RY
for <...@gmail.com>; Sun, 29 Jan 2023 00:49:00 +0100 (CET)



This is google receiving it and verifying SPF:


Received: from relayout04-q02.e.movistar.es
(relayout04-q02.e.movistar.es. [86.109.101.172])
by mx.google.com with ESMTPS id
p19-20020a1c5453000000b003dc1d5ebb1fsi3235601wmi.95.2023.01.28.15.49.00
for <...@gmail.com>
(version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
Sat, 28 Jan 2023 15:49:00 -0800 (PST)

Received-SPF: pass (google.com: domain of ...@telefonica.net designates
86.109.101.172 as permitted sender) client-ip=86.109.101.172;

Authentication-Results: mx.google.com;
spf=pass (google.com: domain of ...@telefonica.net designates
86.109.101.172 as permitted sender) smtp.mailfrom=...@telefonica.net;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=telefonica.net



As you can see, Google doesn't care that the machine where I run Alpine,
at 79.151.X.Y, is not authorized. It doesn't even look at it. What it
looks is at the SMTP at 86.109.101.172, my ISP relay.


--
Cheers, Carlos.

[Adam H. Kerman]

John Levine <jo...@taugh.com> wrote:
>According to Adam H. Kerman <a...@chinet.com>:

>>As I've explained, the SPF policy has an -all restriction and rejects
>>the IP address of my host. It's literally in all the failure notices
>>I've received.

>I believe it, but I am also guessing that those are from very small systems.

Gmail?

>As I said a few messages ago, serious mail systems ignore -all because there
>are so many false positives. The place where -all causes trouble in practice
>is with DMARC policies which depend on SPF alignment.

>>I cannot explain why your -all restriction isn't tripping you up.

>See above.

>In any event, if your mail provider insists on a stupid configuration,
>either you live with it, or you take your business elsewhere.

I've explained and I've explained and I've explained. For bizarre
reasons, nearly everyone in this thread decided I was misrepresenting
the situation or flat-out lying. There's no reason to re-interpret what
I've written.

It's not the email provider. It's our very own SPF policy. I don't have
privileges. The guy who does isn't interested in changing it. I have no
idea how the SPF policy was put there; maybe the domain registrar.

[Adam H. Kerman]

J.O. Aho <us...@example.net> wrote:

>>. . .

>Still do not specify anything about your smtp setup, so if you have
>issues due of SPF then your error is in the smtp-server in your ~/.pinerc

At this point, you're trolling me. You are absolutely NOT reading
anything at all I've written and you have said NOTHING relevant.

[John Levine]

It appears that Adam H. Kerman <a...@chinet.com> said:

>John Levine <jo...@taugh.com> wrote:
>>According to Adam H. Kerman <a...@chinet.com>:
>
>>>As I've explained, the SPF policy has an -all restriction and rejects
>>>the IP address of my host. It's literally in all the failure notices
>>>I've received.
>
>>I believe it, but I am also guessing that those are from very small systems.
>
>Gmail?

I know people at Gmail and I would be very surprised if they rejected solely for SPF failure.

>>In any event, if your mail provider insists on a stupid configuration,
>>either you live with it, or you take your business elsewhere.
>
>I've explained and I've explained and I've explained. For bizarre
>reasons, nearly everyone in this thread decided I was misrepresenting
>the situation or flat-out lying. There's no reason to re-interpret what
>I've written.

This seems appropriate: https://xkcd.com/1984/

[Adam H. Kerman]

John Levine <jo...@taugh.com> wrote:
>It appears that Adam H. Kerman <a...@chinet.com> said:
>>John Levine <jo...@taugh.com> wrote:
>>>According to Adam H. Kerman <a...@chinet.com>:

>>>>As I've explained, the SPF policy has an -all restriction and rejects
>>>>the IP address of my host. It's literally in all the failure notices
>>>>I've received.

>>>I believe it, but I am also guessing that those are from very small systems.

>>Gmail?

>I know people at Gmail and I would be very surprised if they rejected
>solely for SPF failure.

Got it. I'm the one who lied about the failure notice.

>>>. . .

[J.O. Aho]

On 29/01/2023 01:04, Carlos E.R. wrote:

> This is google receiving it and verifying SPF:
>
>
> Received: from relayout04-q02.e.movistar.es
> (relayout04-q02.e.movistar.es. [86.109.101.172])
>         by mx.google.com with ESMTPS id
> p19-20020a1c5453000000b003dc1d5ebb1fsi3235601wmi.95.2023.01.28.15.49.00
>         for <...@gmail.com>
>         (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305
> bits=256/256);
>         Sat, 28 Jan 2023 15:49:00 -0800 (PST)
>
> Received-SPF: pass (google.com: domain of ...@telefonica.net designates
> 86.109.101.172 as permitted sender) client-ip=86.109.101.172;
>
> Authentication-Results: mx.google.com;
>        spf=pass (google.com: domain of ...@telefonica.net designates
> 86.109.101.172 as permitted sender) smtp.mailfrom=...@telefonica.net;
>        dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=telefonica.net
>
>
>
> As you can see, Google doesn't care that the machine where I run Alpine,
> at 79.151.X.Y, is not authorized. It doesn't even look at it. What it
> looks is at the SMTP at 86.109.101.172, my ISP relay.

It's about the delivering systems IP, not about what is the origin
senders IP, but OP is skeptical to most told to him.

As OP not posted any real information, there are just a few options:

- He send it directly from the client to the recipients mx server as
local sendmail
- He uses a mail server which ain't included in the SPF record

Had he provided the bounce mail with header, then I think we could see
the real fault (misconfiguration of DMARC/SPF or alpine/pine).

--

//Aho

[Carlos E.R.]

Right. Lacking the actual report, we can only make guesses based on his
interpretation, which may be correct or not.

--
Cheers, Carlos.

[Adam H. Kerman]

J.O. Aho <us...@example.net> wrote:

>It's about the delivering systems IP, not about what is the origin
>senders IP, but OP is skeptical to most told to him.

>As OP not posted any real information, there are just a few options:

I posted real information. You simply chose to call me a liar.

>- He send it directly from the client to the recipients mx server as
>local sendmail

I did nothing of the kind.

>- He uses a mail server which ain't included in the SPF record

I am doing nothing of the kind.

>Had he provided the bounce mail with header, then I think we could see
>the real fault (misconfiguration of DMARC/SPF or alpine/pine).

There is no DMARC policy, yet several of you chose to accuse me of lying
about that as well. Why the hell did you raise pine? Pine never had a
roles feature. Now I'm also lying about using alpine.

[Carlos E.R.]

On 2023-01-29 18:13, Adam H. Kerman wrote:
> J.O. Aho <us...@example.net> wrote:
>
>> It's about the delivering systems IP, not about what is the origin
>> senders IP, but OP is skeptical to most told to him.
>
>> As OP not posted any real information, there are just a few options:
>
> I posted real information. You simply chose to call me a liar.

Sorry, no, you did not.

We did not see the reject email.

And no, no one accuses you of lying.

--
Cheers, Carlos.

[Adam H. Kerman]

Several of you, including you, accused me of failing to provide
information. It's quoted right there above. That's an accusion of having
committed a lie of omission. Hey, it's unmoderated Usenet. You get to
address me however you wish. But kindly don't deny what you actually
did.

The MAIL FROM domain [redacted] has an SPF record with
a hard 550-5.7.26 fail policy (-all) but it fails to
pass SPF checks with the ip [redacted]: 550-5.7.26.

That's from Gmail with numbered references to their policy document.

If you were honest, you'd own up to the fact that I did not misinterpret
that. But you're not going to do that because you'd prefer to flame me.
You then let yourself off the hook for bad behavior by denying exactly
what you've been doing.

I'm a long-time Usenet participant. I've flamed people over the years
who refuse to get it and aren't listening. I have no patience with those
types. I'm no innocent here.

But I do try not to be a hypocrite. I have, at times, owned up to being
in the wrong. I'm not wrong here. I did not misread that failure notice.

I stated that the failure notices were about SPF. It's just not possible
to misinterpret a failure notice when its plain language is read for
understanding.

You and others accused me of having a DMARC policy that I failed
to disclose. I'm not going to be able to prove a negative to your
satisfaction. If you were a decent person, you'd take my word for it
that DMARC is irrelevant to my issue, but you've clearly demonstrated
that you won't.

[J.O. Aho]

On 29/01/2023 18:13, Adam H. Kerman wrote:
> J.O. Aho <us...@example.net> wrote:
>
>> It's about the delivering systems IP, not about what is the origin
>> senders IP, but OP is skeptical to most told to him.
>
>> As OP not posted any real information, there are just a few options:
>
> I posted real information. You simply chose to call me a liar.
>
>> - He send it directly from the client to the recipients mx server as
>> local sendmail
>
> I did nothing of the kind.

So what is your configuration for outgoing smtp in your alpine?

>> - He uses a mail server which ain't included in the SPF record
>
> I am doing nothing of the kind.

give us the smtp server name and the domain name that you are sending for.

>> Had he provided the bounce mail with header, then I think we could see
>> the real fault (misconfiguration of DMARC/SPF or alpine/pine).
>
> There is no DMARC policy, yet several of you chose to accuse me of lying
> about that as well.

We don't know, we have to just trust your word, then I guess there is no
issue as you said it's not the SPF that caused problem and there is no
DMARC. You need to show something or else we just second guess everything.

> Why the hell did you raise pine? Pine never had a
> roles feature. Now I'm also lying about using alpine.

This is the pine/alpine newsgroup right?
I do see you said you used alpine, but I don't always remember what you
are using and have little interest of going through everything again
when I reply in a general manner.

--

//Aho

[Adam H. Kerman]

J.O. Aho <us...@example.net> wrote:
>On 29/01/2023 18:13, Adam H. Kerman wrote:
>>J.O. Aho <us...@example.net> wrote:

>>>It's about the delivering systems IP, not about what is the origin
>>>senders IP, but OP is skeptical to most told to him.

>>>As OP not posted any real information, there are just a few options:

>>I posted real information. You simply chose to call me a liar.

>>>- He send it directly from the client to the recipients mx server as
>>>local sendmail

>>I did nothing of the kind.

>So what is your configuration for outgoing smtp in your alpine?

I stated what I'm doing in the root article in this thread AND
throughout any number of followups in this thread. For whatever reason,
you think I've lied and have omitted critical information.

At this point, it's clear that any answer I provide will be disbelieved.
I'm being trolled.

>>>. . .

>We don't know, we have to just trust your word, then I guess there is no
>issue as you said it's not the SPF that caused problem and there is no
>DMARC. You need to show something or else we just second guess everything.

No, dude. It doesn't work like that. I haven't forced you to second
guess anything. That's what you chose to do.

>>Why the hell did you raise pine? Pine never had a
>>roles feature. Now I'm also lying about using alpine.

>This is the pine/alpine newsgroup right?
>I do see you said you used alpine, but I don't always remember what you
>are using and have little interest of going through everything again
>when I reply in a general manner.

Your lack of interest in reading what I've written for comprehension is
your problem, not mine. The key point I made all the way back in the
root article is that I used a role to set the SMTP server for sending
messages from mailboxes in the domain with the inappropriate SPF policy.
I repeated that in any number of followups, including followups to your
articles.

You just stated that you aren't interested in what I've written, yet you
ask question after question after question to supposedly obtain
information that was provided way back in the root article of this
thread. No one being conversational would ever do such a thing.

I'm being trolled here. I am now spitting out the hook.

[Carlos E.R.]

On 2023-01-29 20:55, Adam H. Kerman wrote:
> Carlos E.R. <robin_...@es.invalid> wrote:
>> On 2023-01-29 18:13, Adam H. Kerman wrote:
>>> J.O. Aho <us...@example.net> wrote:
>
>>>> It's about the delivering systems IP, not about what is the origin
>>>> senders IP, but OP is skeptical to most told to him.
>
>>>> As OP not posted any real information, there are just a few options:
>
>>> I posted real information. You simply chose to call me a liar.
>
>> Sorry, no, you did not.
>
>> We did not see the reject email.
>
>> And no, no one accuses you of lying.
>
> Several of you, including you, accused me of failing to provide
> information. It's quoted right there above. That's an accusion of having
> committed a lie of omission. Hey, it's unmoderated Usenet. You get to
> address me however you wish. But kindly don't deny what you actually
> did.
>
> The MAIL FROM domain [redacted] has an SPF record with
> a hard 550-5.7.26 fail policy (-all) but it fails to
> pass SPF checks with the ip [redacted]: 550-5.7.26.

That's not enough data... And it is redacted. Fine, you want your
privacy, I understand that, but we can not do an evaluation without the
actual (full) rejection email with full headers and true IPs and names.
You must also understand that.

And the actual configuration file of Alpine is needed, too.

I understand you want your privacy, but without that actual data, it is
impossible to help you.

And no, I'm certainly not accusing you of anything. You are way to
sensitive.

--
Cheers, Carlos.

[J.O. Aho]

On 29/01/2023 22:05, Adam H. Kerman wrote:
> J.O. Aho <us...@example.net> wrote:

>> This is the pine/alpine newsgroup right?
>> I do see you said you used alpine, but I don't always remember what you
>> are using and have little interest of going through everything again
>> when I reply in a general manner.
>
> Your lack of interest in reading what I've written for comprehension is
> your problem, not mine. The key point I made all the way back in the
> root article is that I used a role to set the SMTP server for sending
> messages from mailboxes in the domain with the inappropriate SPF policy.
> I repeated that in any number of followups, including followups to your
> articles.

As I pointed

> You just stated that you aren't interested in what I've written

I said I wasn't interested to reread everything again to see if you use
alpine or pine when I just made a general response to the observation
that you do not really share any information, all you done is saying you
are doing it right, no one has nothing to go on to enlighten you what
you can do to fix your issue.

> , yet you
> ask question after question after question to supposedly obtain
> information that was provided way back in the root article of this
> thread. No one being conversational would ever do such a thing.

You only claim that you done it right, then we can just say, it works as
intended and close the case or do you want help?

--
//Aho

[J.O. Aho]

On 29/01/2023 20:55, Adam H. Kerman wrote:

> Several of you, including you, accused me of failing to provide
> information. It's quoted right there above. That's an accusion of having
> committed a lie of omission. Hey, it's unmoderated Usenet. You get to
> address me however you wish. But kindly don't deny what you actually
> did.
>
> The MAIL FROM domain [redacted] has an SPF record with
> a hard 550-5.7.26 fail policy (-all) but it fails to
> pass SPF checks with the ip [redacted]: 550-5.7.26.

we assume domain redacted = example.net
we assume ip redacted = 0.0.0.0

1. If the spf entry for example.net is "v=spf1 mx:example.net -all"

Then only MX servers for example.net are allowed to send mail, to know
whcih ones those are you can use dig, example: dig -t MX example.net


; <<>> DiG 9.18.10 <<>> -t MX example.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31608
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.net. IN MX

;; ANSWER SECTION:
example.net. 3600 IN MX 10 example.com.
example.net. 3600 IN MX 10 example.org.

;; Query time: 30 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sun Jan 29 23:11:58 CET 2023
;; MSG SIZE rcvd: 149

In this case you can only send from the smtp servers on the exmaple.com
and example.org. Checking the ip, is quite simple with "host
example.com" and "host example.org" and those are most likely different
from the ip of example.net.


2. If the spf entry for example.net is "v=spf1
a:anothermachine.example.net -all"

then just do a "host anothermachine.example.net" to see the ip of the
allowed mail server for sending mail for example.net. I guess that would
in your case not be 0.0.0.0.


3. If the spf entry for example.net is "v=spf1 ip:0.0.0.1 -all"

then sending from 0.0.0.0 will never be accepted.


Sure you can combine those as you want, there is a limit on how many you
can have in a spf record (to overcome that you use includes, but over 10
layers of include will cause problems).

If things are wrongly setup, then you may have "v=spf1 mx:example.net
-all ip:0.0.0.0"
in this case it's only the MX entries for the example.net that are
allowed to send, as the -all comes before the ip:0.0.0.0 which means it
should be ignored.


My guess is that you seen the MX and think it means that exampl.net
itself can send mail, but that really depends if it's included among the
MX records for the domain or not.

This was described in the link I posted in my first reply to this thread.

--

//Aho

[Adam H. Kerman]

Carlos E.R. <robin_...@es.invalid> wrote:
>On 2023-01-29 20:55, Adam H. Kerman wrote:
>>Carlos E.R. <robin_...@es.invalid> wrote:
>>>On 2023-01-29 18:13, Adam H. Kerman wrote:
>>>>J.O. Aho <us...@example.net> wrote:

>>>>>It's about the delivering systems IP, not about what is the origin
>>>>>senders IP, but OP is skeptical to most told to him.

>>>>>As OP not posted any real information, there are just a few options:

>>>>I posted real information. You simply chose to call me a liar.

>>>Sorry, no, you did not.

>>>We did not see the reject email.

>>>And no, no one accuses you of lying.

>>Several of you, including you, accused me of failing to provide
>>information. It's quoted right there above. That's an accusion of having
>>committed a lie of omission. Hey, it's unmoderated Usenet. You get to
>>address me however you wish. But kindly don't deny what you actually
>>did.

>> The MAIL FROM domain [redacted] has an SPF record with
>> a hard 550-5.7.26 fail policy (-all) but it fails to
>> pass SPF checks with the ip [redacted]: 550-5.7.26.

>That's not enough data... And it is redacted. Fine, you want your
>privacy, I understand that, but we can not do an evaluation without the
>actual (full) rejection email with full headers and true IPs and names.
>You must also understand that.

Did I at any point ask you to do any of that?

>. . .

[Henning Hucke]

Adam H. Kerman <a...@chinet.com> wrote:

Hello Adam,

> [...]
> I wonder: Am I receiving all SPF failure messages? Does the recipient
> refusing the connection per our own SPF policies take the position that
> I'm a forger and there's no way to reach the forger to point out the SPF
> restriction, and not send the failure notice?

sorry for answering this posting while having read also most of the later
postings of you and the other discussion participants.

What I understand:
- For business purposes you've got different e-mail addresses and
maildrops in use and you use the the imap servers of these different
mail providers, might it be a hoster with which your business partner
hosts his e-mail stuff, might it be directly the e-mail system of your
business partner, as well as the correcponding smtp servers.
- If you send an e-mail you use the corresponding smtp server against
which you authenticate with the corresponding credentials.
- you send your mail via port smtp (25/tcp) and *not* via port
submission (587/tcp).

Your problem is that you don't get your mails sent further by the mail
system of your business partners and you don't receive - at least not in
every case - what you call an SPF error mail.

If this is a good matching summary of your situation and your problem
state there are several flaws in that.

- It depends on the configurations of the mail systems in which cases
they take SPF informations into account.
With a e-mail hoster its quite probable that they always take SPF into
account if you send mail via smtp even if you authenticate. Then
there is AFAIK no