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