On 29/06/24 15:16, Curtis J Blank via Postfix-users wrote:
Peter, my misunderstanding, sorry. This is what I discovered today in
my testing. I explicitly used 127.0.0.1 and not localhost or so I
thought, I explain that below.
Back on topic. I did some more testing. This was the spampd options used:
SPAMPD_OPTIONS="--host=localhost:10025 --relayhost=localhost:10026
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"
I changed it to:
SPAMPD_OPTIONS="--host=127.0.0.1:10025 --relayhost=127.0.0.1:10026
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"
This would work, kind of, but not the way that you think, see below.
There is no global
mynetworks = something
in main.cf.
mynetworks is immaterial to this, it has nothing to do with this issue.
inet_protocols was set back to:
inet_protocols = all
And all works just fine. So, spampd set to use localhost when everything
in postfix was set to use 127.0.0.1 probably explains why smtp thought
spampd was trying to relay via a ::1 connection and denied it.
So the change you made to spamd changed it so that it no longer listens
on ::1 but rather it now just listens on 127.0.0.1, before it was
listening on both (being set to localhost). There is another setting
which you have set to 127.0.0.1 which controls which connections spamd
will accept mail from, this is not the same setting as the one you just
changed.
So before you had spamd listening on both 127.0.0.1 and on ::1 but only
accepting mail from 127.0.0.1, so if postfix tried to connect from
127.0.0.1 spamd would be happy, but if postfix tried to connect from ::1
spamd would answer the connection (because it's listening) allow postfix
to continue with the RCPT TO stage and then reject the message with a
454 relay access denied response, this causes Postfix to defer the
connection and retry it at a later time, and when it retries there is a
good chance it will try ::1 again. So Postfix sees a good connection
but the spamd is deferring the message.
So what is likely happening now is Postfix still attempts to connect to
::1 (because you didn't change the postfix settings in this regard) but
spamd is no longer listening on ::1 so postfix cannot connect at all.
Postfix seeing this then immediately tries to connect to 127.0.0.1 and
is able to connect to spamd and relay the message. So Postfix is still
configured to connect to the wrong IP but because spamd isn't even
listening on that IP address at all postfix tries the next possibility
which is the correct IP and it does so right away because there is no
deferral.
Note that this is not the most ideal way of solving the problem.
Ideally you want to either configure postfix to never try to connect to
::1 (but only connect to 127.0.0.1) or you want to configure spamd both
listen and accept messages on both ::1 and 127.0.0.1. This way there
should never even be an attempt to connect to a non-working address
(unless spamd actually is down).
But the
part I still don't understand is why smtp was trying to use ::1 when
everything postfix wise is set to use 127.0.0.1.
To answer that I would need to see your config, specifically the output
of the two commands I gave you before.
Everything except this that is:
mydestination = $myhostname, localhost.$mydomain, $mydomain, www.$mydomain
Should this be set to:
mydestination = $myhostname, 127.0.0.1.$mydomain, $mydomain, www.$mydomain
mydestination has nothing to do with this issue.
To keep ::1 from being used? If so oversight on my part, not thinking
that through, so setting it to 127.0.0.1 would probably allow me to
revert the spamd options back to what they were.
Maybe I'll just try it and see.
Send your config.
Peter
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
