From Newsgroup: comp.mail.pine

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?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

It appears that Adam H. Kerman <ahk@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, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

John Levine <johnl@taugh.com> wrote:

It appears that Adam H. Kerman <ahk@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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 2023-01-28 05:36, Adam H. Kerman wrote:

John Levine <johnl@taugh.com> wrote:

It appears that Adam H. Kerman <ahk@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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2023-01-28 05:36, Adam H. Kerman wrote:

John Levine <johnl@taugh.com> wrote:

It appears that Adam H. Kerman <ahk@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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2023-01-28 05:36, Adam H. Kerman wrote:

John Levine <johnl@taugh.com> wrote:

It appears that Adam H. Kerman <ahk@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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Carlos E.R. <robin_listas@es.invalid> wrote:

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

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2023-01-28 05:36, Adam H. Kerman wrote:

John Levine <johnl@taugh.com> wrote:

It appears that Adam H. Kerman <ahk@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 user1@example.com. In a role, when I am
sending messages from user1@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.

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.

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

J.O. Aho <user@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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 28/01/2023 21:13, Adam H. Kerman wrote:

J.O. Aho <user@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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 2023-01-28 20:57, Adam H. Kerman wrote:

Carlos E.R. <robin_listas@es.invalid> wrote:

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

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2023-01-28 05:36, Adam H. Kerman wrote:

John Levine <johnl@taugh.com> wrote:

It appears that Adam H. Kerman <ahk@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 user1@example.com. In a role, when I am
sending messages from user1@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.

For example, I use Alpine, with a role to send emails with somename@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).

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.

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.

Good :-)
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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

On 28/01/2023 21:13, Adam H. Kerman wrote:

J.O. Aho <user@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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Carlos E.R. <robin_listas@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 user1@example.com. In a role, when I am
sending messages from user1@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.

. . .

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

According to Adam H. Kerman <ahk@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.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 28/01/2023 22:39, Adam H. Kerman wrote:

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

On 28/01/2023 21:13, Adam H. Kerman wrote:

J.O. Aho <user@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

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 2023-01-28 23:03, Adam H. Kerman wrote:

Carlos E.R. <robin_listas@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 user1@example.com. In a role, when I am
sending messages from user1@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.

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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

John Levine <johnl@taugh.com> wrote:

According to Adam H. Kerman <ahk@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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

J.O. Aho <user@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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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

John Levine <johnl@taugh.com> wrote:

According to Adam H. Kerman <ahk@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/
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

John Levine <johnl@taugh.com> wrote:

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

John Levine <johnl@taugh.com> wrote:

According to Adam H. Kerman <ahk@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.

. . .

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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])
-a-a-a-a-a-a-a by mx.google.com with ESMTPS id p19-20020a1c5453000000b003dc1d5ebb1fsi3235601wmi.95.2023.01.28.15.49.00
-a-a-a-a-a-a-a for <...@gmail.com>
-a-a-a-a-a-a-a (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
-a-a-a-a-a-a-a 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;
-a-a-a-a-a-a spf=pass (google.com: domain of ...@telefonica.net designates 86.109.101.172 as permitted sender) smtp.mailfrom=...@telefonica.net;
-a-a-a-a-a-a 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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 2023-01-29 12:03, J.O. Aho wrote:

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])
-a-a-a-a-a-a-a-a by mx.google.com with ESMTPS id p19-20020a1c5453000000b003dc1d5ebb1fsi3235601wmi.95.2023.01.28.15.49.00
-a-a-a-a-a-a-a-a for <...@gmail.com>
-a-a-a-a-a-a-a-a (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
-a-a-a-a-a-a-a-a 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;
-a-a-a-a-a-a-a spf=pass (google.com: domain of ...@telefonica.net designates 86.109.101.172 as permitted sender) smtp.mailfrom=...@telefonica.net;
-a-a-a-a-a-a-a 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).

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

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

J.O. Aho <user@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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 2023-01-29 18:13, Adam H. Kerman wrote:

J.O. Aho <user@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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2023-01-29 18:13, Adam H. Kerman wrote:

J.O. Aho <user@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 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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 29/01/2023 18:13, Adam H. Kerman wrote:

J.O. Aho <user@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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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

On 29/01/2023 18:13, Adam H. Kerman wrote:

J.O. Aho <user@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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2023-01-29 18:13, Adam H. Kerman wrote:

J.O. Aho <user@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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 29/01/2023 22:05, Adam H. Kerman wrote:

J.O. Aho <user@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



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Carlos E.R. <robin_listas@es.invalid> wrote:

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

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2023-01-29 18:13, Adam H. Kerman wrote:

J.O. Aho <user@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?

. . .

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Adam H. Kerman <ahk@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 way to overcome this and therewith to overcome your
problem.
On "private"/onprem/business systems it *should* be the case that if
you send mail via the submission port and sucessfully authenticated it
should work.
It should also work if you authenticate on the smtp port but the
probability is higher that it doesn't work to send via the smtp port
*even* if you successfully authenticate.

You have to ask your bussiness partners to get things done and get the
relevant informations. This is nothing with which anybody else can
help you.

- There is no such thing as an SPF error mail.
There are indeed delivery status messages and error messages which
contain parts of the SMTP dialogue and if the remote system states in
the rejection reply in the SMTP dialogue that the mail is rejected
because of SPF based reasons then one might name this as a "SPF error
message".
*Yes*! These messages should *all* show up in the maildrop of the
corresponding sender e-mail address / account.

All in all this suggests poorly configured setups. At least sending
e-mails for "outside" via the submission port especialy with
authentication if coming from "the outside" should work. The same
applies to the smtp port but its also valid to disbale this on the smtp
port.
Checking SPF for deliveries via the submission port is bullshit but valid
if not mandatory on the smtp port.

So taking it all together: you better should send your mails via the
submission port and your business partners and/or their mail service
providers should disbale SPF verifications for deliveries via the
submission port.

Best regards
Henning
--
Applause, n:
The echo of a platitude from the mouth of a fool.
-- Ambrose Bierce
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 2023-01-30 00:05, Adam H. Kerman wrote:

Carlos E.R. <robin_listas@es.invalid> wrote:

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

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2023-01-29 18:13, Adam H. Kerman wrote:

J.O. Aho <user@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?

Yes.
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Henning Hucke <h_hucke+news.reply@newsmail.aeon.icebear.org> wrote:

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

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

I'm not using a maildrop as the alpine documentation defines it. I have
always used IMAP, since I started using the client in the '90s, I think
since Pine 2.3. Glancing at the chronology, that makes sense since IMAP
had become mature at that point.

IMAP is not giving me any grief.

I use roles for each address I send messages from to set the SMTP
server associated with the domain.

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

A few years ago, Eduardo recommended using implicit TLS/SSL. He stated
that port 465 is the default with the use of the /ssl parameter.

I'm not using port 587 at all. I followed Eduardo's advice.

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.

I wasn't sure about that, which is why I asked about it. Carlos thinks
that I have been receiving the SPF failure notices.

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

. . .

You have to ask your bussiness partners to get things done and get the
relevant informations. This is nothing with which anybody else can
help you.

Oh, I know. I don't have privileges over the DNS zone file to revise the
SPF record and I haven't persuaded the guy who does to address this.

Thanks for your thoughts.

. . .

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

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

Once again, hello Adam.

[...]
I'm not using a maildrop as the alpine documentation defines it. I have always used IMAP, since I started using the client in the '90s, I think
since Pine 2.3. Glancing at the chronology, that makes sense since IMAP
had become mature at that point.

Erm... You *are* using /a maildrop/ since in the end your mails are
stored somewhere so somewhere they are local and in some format in some
file. IMAP is the protocol which you use to access your maildrop(s).

[...]
I use roles for each address I send messages from to set the SMTP
server associated with the domain.

Well, thats what I do too. For most of the roles I use my local mail
server but nonetheless I use roles and I use different smtp servers.

[...]
A few years ago, Eduardo recommended using implicit TLS/SSL. He stated
that port 465 is the default with the use of the /ssl parameter.

I'm not using port 587 at all. I followed Eduardo's advice.

I see. But its always a good idea to also make yourself your own
thoughts. Especially if it comes to smtp transmissions in contrast to submission transmissions.
In your case its IMHO less the question whether or not you use natively encrypted versions of a service but whether you use smtp or submission. Deliveries of authenticated clients from anywhere shouldn't SPF checked
on the submission service while all and every delivery should be checked in several ways on the smtp service.

[...]
I wasn't sure about that, which is why I asked about it. Carlos thinks
that I have been receiving the SPF failure notices.

As I already stated there is no such thing like an SPF failure notice; especialy if we are talking about a mail about a failure.
What I suppose is that you are talking about a message which alpine
displays which shows a/the relevant part of the smtp protocol reply of
the remote system you are using that says that it rejects your mail
because you are sending from an IP which is not mentioned in the SPF
record for the domain which you use in this case for sending your mail.

And this is totally legit since you are using the smtp service.

[...]
Oh, I know. I don't have privileges over the DNS zone file to revise the
SPF record and I haven't persuaded the guy who does to address this.

Erm... I also wouldn't change my SPF records to just enable you to send
mail through my smtp service from anywhere. Instead I would enable you
to send your mail through my submission service which wouldn't check SPF records but certainly require authentication to be allowed to use it
(from outside of my own network).

[...]

Regards
Henning
--
Forecast, n:
A prediction of the future, based on the past, for
which the forecaster demands payment in the present.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 2023-01-31 07:44, Henning Hucke wrote:

...

[...]
A few years ago, Eduardo recommended using implicit TLS/SSL. He stated
that port 465 is the default with the use of the /ssl parameter.

I'm not using port 587 at all. I followed Eduardo's advice.

I see. But its always a good idea to also make yourself your own
thoughts. Especially if it comes to smtp transmissions in contrast to submission transmissions.
In your case its IMHO less the question whether or not you use natively encrypted versions of a service but whether you use smtp or submission. Deliveries of authenticated clients from anywhere shouldn't SPF checked
on the submission service while all and every delivery should be checked in several ways on the smtp service.

In the example I posted, taken from an actual test email, my Alpine
passes over email to my local postfix, which passes email over to my ISP (telefonica.net) using port 25 and authentication, which then "sends" to gmail. And gmail checks the SPF and doesn't complain.

(context: in my country, ISPs do not block port 25, or any other port).
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 31/01/2023 11:54, Carlos E.R. wrote:

In the example I posted, taken from an actual test email, my Alpine
passes over email to my local postfix, which passes email over to my ISP (telefonica.net) using port 25 and authentication, which then "sends" to gmail. And gmail checks the SPF and doesn't complain.

(context: in my country, ISPs do not block port 25, or any other port).

Here they do, so you are forced to use submission port, so I don't
really think so much about the issues using port 25, but I have seen a
trend where some administrators recommendation to not allow
authentication on port 25, just have it on the submission port.
I don't know how common that is, as I seldom have to use other mail
servers and current employer uses that web based mail system that a big American company in the north west is supplying.
--
//Aho
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Henning Hucke <h_hucke+news.reply@newsmail.aeon.icebear.org> wrote:

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

[...]
I'm not using a maildrop as the alpine documentation defines it. I have >>always used IMAP, since I started using the client in the '90s, I think >>since Pine 2.3. Glancing at the chronology, that makes sense since IMAP
had become mature at that point.

Erm... You *are* using /a maildrop/ since in the end your mails are
stored somewhere so somewhere they are local and in some format in some
file. IMAP is the protocol which you use to access your maildrop(s).

From the alpine help text

What is a Mail Drop?

In some situaions it may make sense to have your
mail delivered to one folder (the Mail Drop) and then
when you want to read mail that has been delivered to
the Mail Drop folder Alpine will move it to another
destination folder. Often the Mail Drop will be a
remote folder and messages will be moved from there
to a local destination folder.

One example where this might make sense is if the
Mail Drop folder is accessible only with the POP
protocol. You could designate your POP inbox as the
Mail Drop folder and have Alpine move mail from there
to a local (on the same machine Alpine is running on)
destination folder, where you'll read it.

I do not use this feature.

. . .

In your case its IMHO less the question whether or not you use natively >encrypted versions of a service but whether you use smtp or submission. >Deliveries of authenticated clients from anywhere shouldn't SPF checked
on the submission service while all and every delivery should be checked in >several ways on the smtp service.

I agree with you. It would make my life easier, yes, if SPF weren't
being checked under these circumstances. Nevertheless, my legitimate
messages I send through the SMTP server associated with the domain get
rejected based on my own SPF policy which includes -all.

[...]
I wasn't sure about that, which is why I asked about it. Carlos thinks
that I have been receiving the SPF failure notices.

As I already stated there is no such thing like an SPF failure notice; >especialy if we are talking about a mail about a failure.

You are going to have to believe me on this one. I have an archive
folder in which I keep notices that state that the message was not
delivered due to failing SPF policy. If I weren't being notified, I
wouldn't have even known I was affected by this.

What I suppose is that you are talking about a message which alpine
displays . . .

No. I am notified in a message.

[...]
Oh, I know. I don't have privileges over the DNS zone file to revise the >>SPF record and I haven't persuaded the guy who does to address this.

Erm... I also wouldn't change my SPF records to just enable you to send
mail through my smtp service from anywhere.

From anywhere? Don't be ridiculous.

From what I've read about SPF, it's intended that specific hosts be listed, either by FQDN or IP. Obviously, I have the alpine mail client installed
on a specific host that should be listed in the SPF policy. The guy with privileges has had his own mail rejected due to SPF policy for the same
reason. He's ignoring the problem. He stopped sending messages with the business address on From. Instead, he uses his personal email address
to send business messages.

Instead I would enable you to send your mail through my submission service >which wouldn't check SPF records but certainly require authentication
to be allowed to use it (from outside of my own network).

This is irrelevant. The MX host in the receiving network, checking our
own SPF policy, rejects the message even though I was not prevented from sending through the SMTP server.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

Carlos E.R. <robin_listas@es.invalid> wrote:

. . .

In the example I posted, taken from an actual test email, my Alpine
passes over email to my local postfix, which passes email over to my ISP >(telefonica.net) using port 25 and authentication, which then "sends" to >gmail. And gmail checks the SPF and doesn't complain.

(context: in my country, ISPs do not block port 25, or any other port).

Nothing in your personal setup is applicable to my situation. There is
no authentication on port 25. That's never been its purpose.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On 2023-01-31 15:24, J.O. Aho wrote:

On 31/01/2023 11:54, Carlos E.R. wrote:

In the example I posted, taken from an actual test email, my Alpine
passes over email to my local postfix, which passes email over to my
ISP (telefonica.net) using port 25 and authentication, which then
"sends" to gmail. And gmail checks the SPF and doesn't complain.

(context: in my country, ISPs do not block port 25, or any other port).

Here they do, so you are forced to use submission port, so I don't
really think so much about the issues using port 25, but I have seen a
trend where some administrators recommendation to not allow
authentication on port 25, just have-a it on the submission port.
I don't know how common that is, as I seldom have to use other mail
servers and current employer uses that web based mail system that a big American company in the north west is supplying.

I know.

But my point is that gmail knows what server in the chain it must verify
for SPF, and which to ignore, independently of using the submission port
or not.

It is probably simple: it just checks the previous server, the one that
is pushing email to gmail. And that one is authorized.
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2