On Thu, Jan 20, 2022 at 12:01:46PM -0500, Joe Acquisto-j4 
<j...@j4computers.com> wrote:

> > On Tue, Jan 18, 2022 at 07:22:40PM -0500, Joe Acquisto-j4 
> > <j...@j4computers.com> 
> > wrote:
> > 
> >> . . .
> >> > I would imagine that Postfix can only authenticate to
> >> > servers that have entries in /etc/postfix/sasl_passwd.
> >> > 
> >> >   smtp_sasl_password_maps (default: empty)
> >> > 
> >> >     Optional Postfix SMTP client lookup tables with one
> >> >     username:password entry per sender, remote hostname
> >> >     or next-hop domain. Per-sender lookup is done only
> >> >     when sender-dependent authentication is enabled. If
> >> >     no username:password entry is found, then the
> >> >     Postfix SMTP client will not attempt to
> >> >     authenticate to the remote host.
> >> > 
> >> > But it seems unlikely that you'd have put an entry there
> >> > for a server of yours that doesn't authenticate.
> >> > 
> >> > Perhaps you need to add that server to debug_peer_list
> >> > and see what the extra logs say.
> >> > 
> >> > cheers,
> >> > raf
> >> 
> >> I believe I have that correct, per examples (and it is working mostly as 
> > expected)
> >> /etc/postfixsasl_passwd takes this form:
> >> 
> >> j...@aaa.com            joea@AAA:ADADAD
> >> j...@aaad.com            j...@aaad.com:ADADAD2
> >> 
> >> As said, this appears to work and does not interfer with incoming
> >> email that goes to a local host, unauthenticated, in all but one case.
> > 
> > Yes, it has nothing to do with incoming connections.
> > It's used by the Postfix SMTP client when making
> > outgoing connections.
> > 
> > Does this mean that the problem you are seeing is with
> > incoming connections? Sorry, but I was under the
> > impression that your problem was that Postfix's SMTP
> > client was trying to authenticate itself to a remote
> > server when delivering mail somewhere (presumably
> > because that remote server required it). If the problem
> > is that an incoming SMTP connection is coming from a
> > remote client, and your Postfix is insisting on that
> > connection authenticating itself, then that's a very
> > different thing.
> > 
> >> joe a
> > 
> > cheers,
> > raf
> 
> Sorry for the confusion.  I will refrain from any self-deprecating attempts 
> at humor. 
> 
> It is an issue with email that postfix has received, via fetchmail, and is
> attempting to deliver to another system.  Authentication is being 
> attempted, without it being required or requested, at least as far as I can 
> tell.

That doesn't sound right. Add that remote server to debug_peer_list
to increase the debugging when sending mail to it.

> Any "normal" mail that is fetched from that gmail account, or others,
> delivers with no apparent attempt to authenticate.  All authentication
> should fail, in any case, as it is not configured on the target server.

If you configure the remote server as well, you can add the
first host to its debug_peer_list as well.

> I have attempted to examine the subject email while in the deferred
> queue (postcat) and comparing it to other examples. Nothing jumped
> out at me.
> 
> Did not find a way to route mail to the deferred queue so as to revert to
> smtp_sender_dependent_authentication = no and send a duplicate 
> email, then compare the two. 
> 
> This may not be worth further effort as it is a rather problematic way
> for me to test and maybe should be abandoned.  I've just got it in mind
> there is nothing "wrong" with it and it "should" work and wonder why.   
> 
> But, what do I know?  Thanks for the follow up.   
> 
> joe a

Good luck.

cheers,
raf

Reply via email to