From Newsgroup: comp.os.linux.misc

When I started to rebuild my home server somplex, which involves a mail
server, people here suggested that it would be simpler to scrap my 15
year old sendmail setup and switch to postfix, rather than to figure out
where things were breaking.

Indeed, it was very easy to get it set up where I can RECEIVE email,
but I cannot SEND email (except for some very limited circumstances).

IMAP (with STARTTLS link encryption) works flawlessly.
Incoming email from strangers works very good as well.

But when my Windows PC that sits on the same LAN tries to submit
outgoing mail messages, they fail to go out. It appears that
postfix considers them prohibited relaying, even though they are
addressed to my own mailbox on my own local mail server.

Strangers like customers of Gmail can send me email to that same
mailbox. But if my desktop at work tries to send a message "From"
my own email address, it never reaches the postfix incoming server
through the NAT server. The attempted connection never hits
/var/log/maillog. But if I - from that same outside PC - send it
using my company email address (which is hosted on RackSpace) it gets
delivered cleanly.

How do I turn on some logging that for example can tell me which local
TCP port (25, 587, 465, 2525) and which encryption overlay (if any)
is used for them to login? I think I only have 25 and 587 enabled.

I am stumped.
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Thu, 26 Feb 2026 00:36:32 -0000 (UTC), Lars Poulsen wrote:

But when my Windows PC that sits on the same LAN tries to submit
outgoing mail messages, they fail to go out. It appears that
postfix considers them prohibited relaying, even though they are
addressed to my own mailbox on my own local mail server.

<https://manpages.debian.org/postconf(5)>

As a starting point, I assume you have rCLpermit_mynetworksrCY listed in
your rCLsmtpd_relay_restrictionsrCY. In which case, make sure your rCLmynetworksrCY sitting includes all the appropriate subnets for
relaying, and only those.

You can use the rCLpostconf -prCY to display all current configuration settings, whether explicit or defaulted.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-02-26, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Thu, 26 Feb 2026 00:36:32 -0000 (UTC), Lars Poulsen wrote:

But when my Windows PC that sits on the same LAN tries to submit
outgoing mail messages, they fail to go out. It appears that
postfix considers them prohibited relaying, even though they are
addressed to my own mailbox on my own local mail server.

<https://manpages.debian.org/postconf(5)>

As a starting point, I assume you have rCLpermit_mynetworksrCY listed in
your rCLsmtpd_relay_restrictionsrCY. In which case, make sure your rCLmynetworksrCY sitting includes all the appropriate subnets for
relaying, and only those.

You can use the rCLpostconf -prCY to display all current configuration settings, whether explicit or defaulted.

Thank you!!
I think this may have solved this problem, so now I can get to
see what the next blockage will be.

As you know, "postconf -p" produces around 950 lines of output,
so unless you know what to "grep" for, you are lost.
I had read the hint in the comments in main.cf to look in
manual section postconf(5), but it does not mention permit_mynetworks

I am puzzled, as to why this is not set by default. I thought this was
the reason why I was defining the list of mynetworks.

And to Carlos: In the RedHat distributions, the sendmail/postfix/imapd
logs are in /var/log/maillog, /var/log/mail is a directory, containing
only /var/log/mail/statistics.
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

In comp.os.linux.misc Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-02-26, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Thu, 26 Feb 2026 00:36:32 -0000 (UTC), Lars Poulsen wrote:

But when my Windows PC that sits on the same LAN tries to submit
outgoing mail messages, they fail to go out. It appears that
postfix considers them prohibited relaying, even though they are
addressed to my own mailbox on my own local mail server.

<https://manpages.debian.org/postconf(5)>

As a starting point, I assume you have rCLpermit_mynetworksrCY listed in
your rCLsmtpd_relay_restrictionsrCY. In which case, make sure your
rCLmynetworksrCY sitting includes all the appropriate subnets for
relaying, and only those.

You can use the rCLpostconf -prCY to display all current configuration
settings, whether explicit or defaulted.

Thank you!!
I think this may have solved this problem, so now I can get to
see what the next blockage will be.

As you know, "postconf -p" produces around 950 lines of output,
so unless you know what to "grep" for, you are lost.
I had read the hint in the comments in main.cf to look in
manual section postconf(5), but it does not mention permit_mynetworks

I am puzzled, as to why this is not set by default. I thought this was
the reason why I was defining the list of mynetworks.

mynetworks can't be "defaulted", because each site has a different
network layout. And if it were "defaulted" then postfix with that
default would be an "open relay". It (postfix) begins in "no relay"
state, and you have to explicitly enable allowing such from parts of
your network setup you want to allow.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-02-26, Rich <rich@example.invalid> wrote:

In comp.os.linux.misc Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-02-26, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Thu, 26 Feb 2026 00:36:32 -0000 (UTC), Lars Poulsen wrote:

But when my Windows PC that sits on the same LAN tries to submit
outgoing mail messages, they fail to go out. It appears that
postfix considers them prohibited relaying, even though they are
addressed to my own mailbox on my own local mail server.

<https://manpages.debian.org/postconf(5)>

As a starting point, I assume you have rCLpermit_mynetworksrCY listed in >>> your rCLsmtpd_relay_restrictionsrCY. In which case, make sure your
rCLmynetworksrCY sitting includes all the appropriate subnets for
relaying, and only those.

You can use the rCLpostconf -prCY to display all current configuration
settings, whether explicit or defaulted.

Thank you!!
I think this may have solved this problem, so now I can get to
see what the next blockage will be.

As you know, "postconf -p" produces around 950 lines of output,
so unless you know what to "grep" for, you are lost.
I had read the hint in the comments in main.cf to look in
manual section postconf(5), but it does not mention permit_mynetworks

I am puzzled, as to why this is not set by default. I thought this was
the reason why I was defining the list of mynetworks.

mynetworks can't be "defaulted", because each site has a different
network layout. And if it were "defaulted" then postfix with that
default would be an "open relay". It (postfix) begins in "no relay"
state, and you have to explicitly enable allowing such from parts of
your network setup you want to allow.

I was expecting that once I have set mynetworks, those networks would
allowed to do relaying. Or that IF I need to explicitly set
permit_mynetworks, there would be a note to that effect in the area
where I set mynetworks. Instead, there is a note pointing to a man page
that actually does not contain the needed information.

And would setting mynetworks to default to the set of networks that
are directly attached to the host where postfix is running, be safe
enough?
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-02-26, Lars Poulsen <lars@beagle-ears.com> wrote:

Thank you!!
I think this may have solved this problem, so now I can get to
see what the next blockage will be.

The next stop was quite predictable: GMail will not accept mail from my
domain anymore. And to find out why, I need to set up Postmaster Tools
and register my domain(s) so I can see the reputation. Google tells me
to add a new TXT record and/or a CNAME record to my DNS. I have now
done both of these, but Google says they do not see these records.
"Try again in a few minutes". - it's been several hours now.

I already have SPF records in place.

By the way: Does anyone have a tool to convert the DMARC reports
into a readable table? John L, maybe?
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

In comp.os.linux.misc Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-02-26, Lars Poulsen <lars@beagle-ears.com> wrote:

Thank you!!
I think this may have solved this problem, so now I can get to
see what the next blockage will be.

The next stop was quite predictable: GMail will not accept mail from my domain anymore. And to find out why, I need to set up Postmaster Tools
and register my domain(s) so I can see the reputation. Google tells me
to add a new TXT record and/or a CNAME record to my DNS. I have now
done both of these, but Google says they do not see these records.
"Try again in a few minutes". - it's been several hours now.

I already have SPF records in place.

One wonders how DNS settings could possibly be the issue if the
same server was sending mail to them successfully with sendmail.
Anyway there are other online email deliverability tools that might
better highlight any issues, such as at viewdns.info and mxtoolbox.com

https://viewdns.info/dnsreport/
https://mxtoolbox.com/SuperTool.aspx

By the way: Does anyone have a tool to convert the DMARC reports
into a readable table? John L, maybe?

To be honest years ago I figured this out, wrote a script to run
it regularly from Cron, but never actually got it set up. Possibly
there was some bug which I couldn't raise enough enthusiasm to fix.

To make a HTML table you can use the XSL stylesheet here, and
xsltproc:
https://www.tana.it/sw/dmarc-xsl/

Assuming you have a mailbox "dmarc_mailbox" dedicated to DMARC
reports, this the manual process described in my notes:

mkdir -p ~/dmarc/zip ~/dmarc/htm
cd dmarc_mailbox
uudeview -p ~/dmarc/zip +e .zip -i -m *
uudeview -p ~/dmarc +e .gz -i -m *

cd ~/dmarc
gunzip *.gz
cd zip
unzip -j '*.zip' -d ../

cd ~/dmarc/htm
[copy/paste XSL stylesheet from webpage to file named dmarc.xsl]
for i in `ls -t ../*.xml`; do xsltproc dmarc.xsl "$i" >> DMARC_reports_`date +%F`.htm; done

If you can be bothered, filter out duplicate <html>, <head>,
<title>, and </html> tags in DMARC_reports_`date +%F`.htm. However
Dillo views the page OK without doing that. Then if all is OK,
delete all the old mail in your "dmarc_mailbox" ready for next
time.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Thu, 26 Feb 2026 18:54:34 -0000 (UTC), Lars Poulsen wrote:

The next stop was quite predictable: GMail will not accept mail from
my domain anymore. ...

I already have SPF records in place.

ThatrCOs all I have place on my personal domain, and last I checked
(just a couple days ago), a friend on gmail.com did receive an email
from me.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

In comp.os.linux.misc Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-02-26, Rich <rich@example.invalid> wrote:

In comp.os.linux.misc Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-02-26, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Thu, 26 Feb 2026 00:36:32 -0000 (UTC), Lars Poulsen wrote:

But when my Windows PC that sits on the same LAN tries to submit
outgoing mail messages, they fail to go out. It appears that
postfix considers them prohibited relaying, even though they are
addressed to my own mailbox on my own local mail server.

<https://manpages.debian.org/postconf(5)>

As a starting point, I assume you have rCLpermit_mynetworksrCY listed in >>>> your rCLsmtpd_relay_restrictionsrCY. In which case, make sure your
rCLmynetworksrCY sitting includes all the appropriate subnets for
relaying, and only those.

You can use the rCLpostconf -prCY to display all current configuration >>>> settings, whether explicit or defaulted.

Thank you!!
I think this may have solved this problem, so now I can get to
see what the next blockage will be.

As you know, "postconf -p" produces around 950 lines of output,
so unless you know what to "grep" for, you are lost.
I had read the hint in the comments in main.cf to look in
manual section postconf(5), but it does not mention permit_mynetworks

I am puzzled, as to why this is not set by default. I thought this was
the reason why I was defining the list of mynetworks.

mynetworks can't be "defaulted", because each site has a different
network layout. And if it were "defaulted" then postfix with that
default would be an "open relay". It (postfix) begins in "no relay"
state, and you have to explicitly enable allowing such from parts of
your network setup you want to allow.

I was expecting that once I have set mynetworks, those networks would
allowed to do relaying. Or that IF I need to explicitly set permit_mynetworks, there would be a note to that effect in the area
where I set mynetworks. Instead, there is a note pointing to a man page
that actually does not contain the needed information.

At least on the main.cf I have, there is info related to mynetworks_style
and mynetworks. The big important one is:

# Alternatively, you can specify the mynetworks list by hand, in
# which case Postfix ignores the mynetworks_style setting.

So mynetworks overrides mynetworks_style if it is set.

But, how did you set mynetworks? Did you specify a network address or
an IP address? For it (mynetworks) to work right for a 'network' you
enter network addresses. So if you use 10.0.0.0/24 as your network,
you'd put in 10.0.0.0/24 to allow any IP on that network to use the
server.

But if you put in just an ip: 10.0.0.1, then only 10.0.0.1 is allowed
to use the server.

And would setting mynetworks to default to the set of networks that
are directly attached to the host where postfix is running, be safe
enough?

That depends upon what else is attached to that network. If it is only
your local network, and only your machines, then yes. If it has other
stuff (like a public wifi AP or something) then maybe not.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

Le 26-02-2026, Lars Poulsen <lars@beagle-ears.com> a |-crit-a:

On 2026-02-26, Lars Poulsen <lars@beagle-ears.com> wrote:

Thank you!!
I think this may have solved this problem, so now I can get to
see what the next blockage will be.

The next stop was quite predictable: GMail will not accept mail from my domain anymore. And to find out why, I need to set up Postmaster Tools
and register my domain(s) so I can see the reputation. Google tells me
to add a new TXT record and/or a CNAME record to my DNS. I have now
done both of these, but Google says they do not see these records.
"Try again in a few minutes". - it's been several hours now.

I already have SPF records in place.

You need to have DKIM in place too. If you don't have both, your emails
will be rejected. And you have to find out if your IPs are listed at
things like spamhaus. The website refusing your emails only because they
are listed on spamhaus and the like are just shit but you can't avoid
it and you have to take care of it.

I have nothing against spamhause and the like but they are poorly used
by incompetent morons who will refuse your mails because they haven't
any clue about the basis of their work.

By the way: Does anyone have a tool to convert the DMARC reports
into a readable table? John L, maybe?

You don't need to care about it. When gmail sends you a DMARC report,
it's to tell you one of his servers is trying to spoof your emails. You
can't do anything about it and you don't need to care about it. You just
need to have DMARC configured to have your emails accepted, but it's
only a shitty stupid and useless protocol.

If SPF and DKIM are good ways to prove the validity of your emails,
DMARC is just stupid garbage.

You have to know that yahoo and google are the biggest spammers on earth
and they'll do all they can to keep their monopole. So, you'll have to
comply by their rules even if they are stupid.
--
Si vous avez du temps |a perdre :
https://scarpet42.gitlab.io
--- Synchronet 3.21d-Linux NewsLink 1.2