Hi there,
remember having a similar issue with saslauthd and cut off user names.
Postfix doc has the proper info
http://www.postfix.org/SASL_README.html
%u - The name of the user whose properties are being selected.
%r - The name of the realm to which the user belongs. This could be
On 4/17/20 4:29 PM, Viktor Dukhovni wrote:
> More at:
all links appreciated.
the summary's particularly nicely readable by those of among the minion masses
of normal humans ;-)
> Postfix documentation covers the client side
still among the best, most-exhaustively detailed s/docs/reference
On Fri, Apr 17, 2020 at 06:59:53PM -0400, Wietse Venema wrote:
> Rich Felker:
> > I can see where it could be desirable to log whether delivery was made
> > based on a TLSA record in a signed domain vs an unsigned one, and this
> > necessitates being able to see the AD bit or equivalent. But it
On Fri, Apr 17, 2020 at 07:27:58PM -0400, Rich Felker wrote:
> > No, I have not. Read my message again, then try:
> >
> > dig -t mx nist.gov
> > dig -t tlsa [_25._tcp.]nist-gov.mail.protection.outlook.com
>
> Missing the _25._tcp.
Yes.
> but either way it seems to be a misconfigured
On Fri, Apr 17, 2020 at 03:59:49PM -0700, PGNet Dev wrote:
> Real World DANE Inter-domain email transport
>
> https://static.ptbl.co/static/attachments/169319/1520904692.pdf
More at:
https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
Specific issues:
On Fri, Apr 17, 2020 at 07:01:26PM -0400, Viktor Dukhovni wrote:
> On Fri, Apr 17, 2020 at 06:52:48PM -0400, Rich Felker wrote:
>
> > > There are (unsigned) domains where any attempt to look up TLSA records
> > > times out or otherwise fails. If DANE is to be downgrade-resistant, and
> > > if
Viktor Dukhovni:
> On Fri, Apr 17, 2020 at 06:46:27PM -0400, Wietse Venema wrote:
>
> > 1) Infrastructure mail server. DNS configuration is not supposed
> > to change. People who care about TLSA/DANE will provision a secure
> > and stable DNS resolver.
> >
> > 2) Personal laptop, roaming between
On Fri, Apr 17, 2020 at 06:52:48PM -0400, Rich Felker wrote:
> > There are (unsigned) domains where any attempt to look up TLSA records
> > times out or otherwise fails. If DANE is to be downgrade-resistant, and
> > if logging of DANE-verified connections is to mean anything in terms of
> >
all this back-n-forth on list re: DNSSEC/DANE has resulted in a flurry of
interest among colleagues etc. and i've been getting emails. lots.
for the what/why i've been tossing them Viktor's now just slightly dusty preso
Real World DANE Inter-domain email transport
Rich Felker:
> I can see where it could be desirable to log whether delivery was made
> based on a TLSA record in a signed domain vs an unsigned one, and this
> necessitates being able to see the AD bit or equivalent. But it does
> not justify dropping all protections if you can't see it, just
>
On Fri, Apr 17, 2020 at 06:46:27PM -0400, Wietse Venema wrote:
> 1) Infrastructure mail server. DNS configuration is not supposed
> to change. People who care about TLSA/DANE will provision a secure
> and stable DNS resolver.
>
> 2) Personal laptop, roaming between trusted and untrusted
On Fri, Apr 17, 2020 at 06:27:27PM -0400, Viktor Dukhovni wrote:
> On Fri, Apr 17, 2020 at 06:19:18PM -0400, Rich Felker wrote:
>
> > This reasoning is why I consider it harmful to limit use of DANE
> > records to situations where the DNS lookup is "trusted" to have been
> > validated -- it just
Viktor Dukhovni:
> > On Apr 17, 2020, at 5:21 PM, Wietse Venema wrote:
> >
> > Possibly, but rest assured that all such features will remain disabled
> > by default for at least one year after there is wide deployment of
> > code that manages the new resolv.conf flag, and there is a documented
On Fri, Apr 17, 2020 at 06:19:18PM -0400, Rich Felker wrote:
> This reasoning is why I consider it harmful to limit use of DANE
> records to situations where the DNS lookup is "trusted" to have been
> validated -- it just encourages flipping a switch to "trust" servers
> that shouldn't be
On Fri, Apr 17, 2020 at 08:13:52PM +0200, Florian Weimer wrote:
> * Wietse Venema:
>
> > Florian Weimer:
> >> * Wietse Venema:
> >>
> >> > Vladimir Lomov:
> >> >> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with
> >> >> 'options trust-ad' and postfix 3.5.0 or it is depend
> On Apr 17, 2020, at 5:21 PM, Wietse Venema wrote:
>
> Possibly, but rest assured that all such features will remain disabled
> by default for at least one year after there is wide deployment of
> code that manages the new resolv.conf flag, and there is a documented
> record of the new failure
Florian Weimer:
> If the administrator has enabled DANE, you could check whether
> RES_TRUSTAD is enabled, and if not, complain loudly that the
> configured name servers are not marked as trusted (and may not even
> support DNSSEC validation). This why we expose the RES_TRUSTAD flag
> via
On Fri, Apr 17, 2020 at 10:17:47PM +0200, Florian Weimer wrote:
> > With the Glibc change as the first step, we have no choice but to
> > restore the status quo ante.
>
> True, but there are different approaches.
>
> If the administrator has enabled DANE, you could check whether
> RES_TRUSTAD
* Viktor Dukhovni:
> The RFC requirement is more than optional, it is unrealistic. Doing
> DNSSEC-validation in each application is not practical, there is no
> broadly deployed (on all the BSDs, Linux, Solaris, ...) library that
> does this, and each application would potentially need its own
>
> On Apr 17, 2020, at 3:59 PM, Florian Weimer wrote:
>
> I don't think it's a gaping security hole. The scope of the flags
> change in dns_query is really small, so it affects that one query
> only. If some library used by Postfix depends on RES_TRUSTAD in its
> intended meaning, it will not
* Wietse Venema:
> Florian Weimer:
>> > My patch does not make security any worse than it was prior to
>> > GLIBC 2.31. This is all I can do for stable Postfix releases:
>> > ensure that shit does not stop working after an OS update.
>> >
>> > Any 'improvements' in Postfix DNSSEC support will
Hi,
I'm setting up a mail server with postfix and dovecot. For SMTP, I want to
use saslauthd with a MySQL backend for which I installed the pam_mysql
library, I'm trying to configure it but there's no luck.
My table schema (users) has 3 columns:
e-mail, password, quota
My /etc/pam.d/smtp
On Fri, Apr 17, 2020 at 08:13:52PM +0200, Florian Weimer wrote:
> > Correct. Until now, Postfix asserts RES_USE_DNSSEC to request
> > validation in a resolver.
>
> RES_USE_DNSSEC is unfortunately misnamed. [...]
Thanks, but neither Wietse nor I need a refresher on DNSSEC.
> > The sysadmin has
Florian Weimer:
> > My patch does not make security any worse than it was prior to
> > GLIBC 2.31. This is all I can do for stable Postfix releases:
> > ensure that shit does not stop working after an OS update.
> >
> > Any 'improvements' in Postfix DNSSEC support will have to be developed
> > in
Viktor Dukhovni:
> On Fri, Apr 17, 2020 at 02:28:10PM +0200, Vieri Di Paola wrote:
>
> > One of these mailbox servers has indeed the same "SMTP name" as one of
> > the Postfix servers. In this case, I do get a message like this in the
> > log: host XXX greeted me with my own hostname YYY
> >
> >
* Wietse Venema:
> Florian Weimer:
>> * Wietse Venema:
>>
>> > Vladimir Lomov:
>> >> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with
>> >> 'options trust-ad' and postfix 3.5.0 or it is depend strongly on used
>> >> 'options'?
>> >
>> > This patch avoids the need to add
On Fri, Apr 17, 2020 at 02:28:10PM +0200, Vieri Di Paola wrote:
> One of these mailbox servers has indeed the same "SMTP name" as one of
> the Postfix servers. In this case, I do get a message like this in the
> log: host XXX greeted me with my own hostname YYY
>
> However, it's only a WARNING,
> On Apr 15, 2020, at 9:39 PM, Viktor Dukhovni
> wrote:
>
> On Wed, Apr 15, 2020 at 09:25:29PM -0400, Bobby Mozumder wrote:
>
>> My Postfix SMTP client, when it sends to my external relay server
>> (connecting to port 587), does a core dump and outputs the following message:
>>
>> Apr 15
Ranjan Maitra:
> On Fri, 17 Apr 2020 15:21:49 +0200 Jan Ceuleers
> wrote:
>
> > On 17/04/2020 15:08, Ranjan Maitra wrote:
> > > Btw, for me, when ifconfig is DOWN, I do not get a down.
> >
> > ifconfig -a fixes that.
> >
>
> Sorry, but not for me:
>
> When down:
>
> $ifconfig -a | egrep
On Fri, 17 Apr 2020 15:21:49 +0200 Jan Ceuleers
wrote:
> On 17/04/2020 15:08, Ranjan Maitra wrote:
> > Btw, for me, when ifconfig is DOWN, I do not get a down.
>
> ifconfig -a fixes that.
>
Sorry, but not for me:
When down:
$ifconfig -a | egrep 'UP|DOWN'
: error fetching interface
Scott Kitterman:
> On Thursday, April 16, 2020 10:31:56 AM EDT Wietse Venema wrote:
> > With the minnimal patch below, it looks like Postfix DANE support
> > will continue to work after a breaking change in Glibc 2.31. Tested
> > on Fedora 32 beta.
> >
> > This patch also deals with the 'multiple
On Thursday, April 16, 2020 10:31:56 AM EDT Wietse Venema wrote:
> With the minnimal patch below, it looks like Postfix DANE support
> will continue to work after a breaking change in Glibc 2.31. Tested
> on Fedora 32 beta.
>
> This patch also deals with the 'multiple definition' errors caused
>
@lbutlr:
> On 16 Apr 2020, at 13:27, Wietse Venema wrote:
> > Any 'improvements' in Postfix DNSSEC support will have to be developed
> > in the Postfix 3.6 release cycle. The results from those =
> 'improvements'
> > will never be merged back into Postfix 3.5 and earlier.
>
> Is this planned for
On 17/04/2020 15:08, Ranjan Maitra wrote:
> Btw, for me, when ifconfig is DOWN, I do not get a down.
ifconfig -a fixes that.
On Fri, 17 Apr 2020 08:05:28 + Gregory Heytings wrote:
>
> Ranjan Maitra:
> >
> >> Wietse Venema:
> >>
> >> Corrected code follows (missing do/done).
> >>
> >> Save to file, chmod +x name-of-file, don't run this script from cron.
> >>
> >> It needs to be started at boot time, or before you
On Thu, Apr 16, 2020 at 7:07 PM Viktor Dukhovni
wrote:
>
> > # postconf -Mf
> > smtp unix - - n - - smtp
> > relay unix - - n - - smtp
>
> Please add:
>
> smtpv unix - - n - - smtp -v
>
* Rich Felker:
> On Wed, Apr 15, 2020 at 08:27:08PM +0200, Florian Weimer wrote:
>> >> I don't understand your PTR example. It seems such a fringe case that
>> >> people produce larger PTR responses because they add all virtual hosts
>> >> to the reverse DNS zone. Sure, it happens, but not
>On Thu, 16 Apr 2020 at 15:40, natan maciej milaszewski
wrote:
>> Sorry about probably dumbest questions. What does it really mean?
>>
>> 552 5.3.4 Message size exceeds fixed limit
>>
>> Apr 16 16:03:48 thebe4 postfix/smtpd[11692]: NOQUEUE: reject: MAIL from
>>
Ranjan Maitra:
Wietse Venema:
Corrected code follows (missing do/done).
Save to file, chmod +x name-of-file, don't run this script from cron.
It needs to be started at boot time, or before you make a VPN
connection.
#!/bin/sh
while :
do
ifconfig xxx | egrep 'UP|DOWN'
sleep 2
On 17 Apr 2020, at 2:52, Ansgar Wiechers wrote:
> On 2020-04-17 Bill Cole wrote:
>> On 17 Apr 2020, at 0:57, Ranjan Maitra wrote:
>>> On Mon, 23 Mar 2020 17:19:42 -0400 (EDT) Wietse Venema wrote:
#!/bin/sh
while :
do
ifconfig xxx | egrep 'UP|DOWN'
sleep 2
On 2020-04-17 Bill Cole wrote:
> On 17 Apr 2020, at 0:57, Ranjan Maitra wrote:
> > On Mon, 23 Mar 2020 17:19:42 -0400 (EDT) Wietse Venema wrote:
> > > #!/bin/sh
> > >
> > > while :
> > > do
> > > ifconfig xxx | egrep 'UP|DOWN'
> > > sleep 2
> > > done | while read status
> > > do
> > >
41 matches
Mail list logo
