>>
> On Sat, Jan 22, 2022 at 05:56:31PM -0500, Joe Acquisto-j4 wrote:
>
>> >> > noauth unix - - n - - smtp
>> >> > -o smtp_sasl_enable=no
>> >> > -o smtp_sender_dependent_authentication=no
>> >> > -o smtp_sasl_password_maps=
>> >>
>>
On Sat, Jan 22, 2022 at 05:56:31PM -0500, Joe Acquisto-j4 wrote:
> >> > noauth unix - - n - - smtp
> >> > -o smtp_sasl_enable=no
> >> > -o smtp_sender_dependent_authentication=no
> >> > -o smtp_sasl_password_maps=
> >>
> >> My initial
> On Sat, Jan 22, 2022 at 05:11:02PM -0500, Joe Acquisto-j4 wrote:
>
>> > Therefore your master.cf file needs to have an least one additional
>> > smtp-based transport, with either SASL disabled entirely, and/or
>> > sender-dependent authentication disabled, or perhaps a variant
>> > password tab
On Sat, Jan 22, 2022 at 05:11:02PM -0500, Joe Acquisto-j4 wrote:
> > Therefore your master.cf file needs to have an least one additional
> > smtp-based transport, with either SASL disabled entirely, and/or
> > sender-dependent authentication disabled, or perhaps a variant
> > password table... B
> On Sat, Jan 22, 2022 at 02:03:29PM -0500, Joe Acquisto-j4 wrote:
>
>> > IIRC Wietse already suggested a work-around, by making the
>> > sender-dependent authentication settings be transport-specific.
>> >
>> > In particular the internal nexthop that does not do SASL should be
>> > handled by a
On Sat, Jan 22, 2022 at 02:03:29PM -0500, Joe Acquisto-j4 wrote:
> > IIRC Wietse already suggested a work-around, by making the
> > sender-dependent authentication settings be transport-specific.
> >
> > In particular the internal nexthop that does not do SASL should be
> > handled by a transport
> On Sat, Jan 22, 2022 at 08:01:27AM +1100, raf wrote:
>
>> > 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
>
On Sat, Jan 22, 2022 at 08:01:27AM +1100, raf wrote:
> > 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.
>
>
On Thu, Jan 20, 2022 at 12:01:46PM -0500, Joe Acquisto-j4
wrote:
> > On Tue, Jan 18, 2022 at 07:22:40PM -0500, Joe Acquisto-j4
> >
> > wrote:
> >
> >> . . .
> >> > I would imagine that Postfix can only authenticate to
> >> > servers that have entries in /etc/postfix/sasl_passwd.
> >> >
> >>
> On Tue, Jan 18, 2022 at 07:22:40PM -0500, Joe Acquisto-j4
>
> 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 cli
On Tue, Jan 18, 2022 at 07:22:40PM -0500, Joe Acquisto-j4
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 table
. . .
> 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
On Mon, Jan 17, 2022 at 10:04:13PM -0500, Joe Acquisto-j4
wrote:
> > On 2022-01-17 at 20:09:55 UTC-0500 (Mon, 17 Jan 2022 20:09:55 -0500)
> > Joe Acquisto-j4
> > is rumored to have said:
> >
> >
> >> Sorry for the garbled message. Looking for the config files, etc that
> >> are normally req
. . .
> OK, here goes -
>
> Using version 3.4.7 packaged by Suse. I use "fetchmail" to retrieve email
> via imap one of which is gmail. The fetched mail is all sent to a local "off
> box" machine, via postfix, spamassassin and clamav, all on the same server.
> The off box machine let's cal
> On 2022-01-17 at 20:09:55 UTC-0500 (Mon, 17 Jan 2022 20:09:55 -0500)
> Joe Acquisto-j4
> is rumored to have said:
>
>
>> Sorry for the garbled message. Looking for the config files, etc that
>> are normally requested.
>
>
> The non-default main.cf settings, formatted for human eyes:
> post
On 2022-01-17 at 20:09:55 UTC-0500 (Mon, 17 Jan 2022 20:09:55 -0500)
Joe Acquisto-j4
is rumored to have said:
Sorry for the garbled message. Looking for the config files, etc that
are normally requested.
The non-default main.cf settings, formatted for human eyes:
postconf -nf
The master.c
On 2022-01-17 at 19:40:39 UTC-0500 (Mon, 17 Jan 2022 19:40:39 -0500)
Joe Acquisto-j4
is rumored to have said:
I have per user SASL authentication working, with one rather odd
exception for which I do not see a cause. It's a bit convoluted to
explain before post that, please just remind me wh
>>>
>> > > One addition:
>
>The swaks command line you'll need to test properly will be something like
this:
swaks -tls -t tar...@example.com --auth-user joea --server
mail.example.com:587
>>>
>>> Thanks, that got me over that hump. Test email went through,
>>>
>>>
>> > One addition:
>>> The swaks command line you'll need to test properly will be something like
>>> this:
>>>
>>> swaks -tls -t tar...@example.com --auth-user joea --server
>>> mail.example.com:587
>>>
>>
>> Thanks, that got me over that hump. Test email went through,
>>
>> Now to transl
>> One addition:
>>
>> The swaks command line you'll need to test properly will be something like
>> this:
>>
>> swaks -tls -t tar...@example.com --auth-user joea --server
>> mail.example.com:587
>>
>
> Thanks, that got me over that hump. Test email went through,
>
> Now to translate this
> One addition:
>
> The swaks command line you'll need to test properly will be something like
> this:
>
> swaks -tls -t tar...@example.com --auth-user joea --server
> mail.example.com:587
>
Thanks, that got me over that hump. Test email went through,
Now to translate this effort into fixin
One addition:
The swaks command line you'll need to test properly will be something like this:
swaks -tls -t tar...@example.com --auth-user joea --server mail.example.com:587
On 2022-01-14 at 12:33:18 UTC-0500 (Fri, 14 Jan 2022 12:33:18 -0500)
Bill Cole
is rumored to have said:
> On 2022-0
On 2022-01-14 at 12:10:23 UTC-0500 (Fri, 14 Jan 2022 12:10:23 -0500)
Joe Acquisto-j4
is rumored to have said:
[...]
> I guess this is going a bit astray, for some viewers anyway, but after
> repeated authentication failures, resorted to (or availed myself of)
> SWAKS and still get authentication f
> On 2022-01-13 at 20:26:53 UTC-0500 (Thu, 13 Jan 2022 20:26:53 -0500)
> Joe Acquisto-j4
> is rumored to have said:
>
> [...]
>> Would it be valid to presume that an SMTP server that can be connected
>> to,
>> securely, via Outlook, Thunderbird and the other common clients, can
>> be
>> connect
On 2022-01-13 at 20:26:53 UTC-0500 (Thu, 13 Jan 2022 20:26:53 -0500)
Joe Acquisto-j4
is rumored to have said:
[...]
Would it be valid to presume that an SMTP server that can be connected
to,
securely, via Outlook, Thunderbird and the other common clients, can
be
connected to via the postfix S
> On 2022-01-13 at 13:09:45 UTC-0500 (Thu, 13 Jan 2022 13:09:45 -0500)
> Joe Acquisto-j4
> is rumored to have said:
>
>> While reading the Postfix SASL doc,
> (http://www.postfix.org/SASL_README.html#client_sasl),
>> I puzzled over a few things.
>>
>> - "The smtp_tls_security_level setting ensu
On 2022-01-13 at 13:09:45 UTC-0500 (Thu, 13 Jan 2022 13:09:45 -0500)
Joe Acquisto-j4
is rumored to have said:
> While reading the Postfix SASL doc,
> (http://www.postfix.org/SASL_README.html#client_sasl),
> I puzzled over a few things.
>
> - "The smtp_tls_security_level setting ensures that the
While reading the Postfix SASL doc,
(http://www.postfix.org/SASL_README.html#client_sasl),
I puzzled over a few things.
- "The smtp_tls_security_level setting ensures that the connection to the
remote smtp server will be encrypted, and smtp_sasl_tls_security_options
removes the prohibition on
28 matches
Mail list logo
