Re: smtpd_recipient_limit=1 ? (was: Re: Tell LMTP who is original recipient?)

2019-05-21 Thread Viktor Dukhovni
> On May 21, 2019, at 6:10 PM, MRob wrote: > > If smtpd_recipient_limit=1 is not bad practice I like to hear opinions about > this. It can also help if you try to do per-user spam filtering during the > SMTP transaction. It remains a terrible (RFC-violating) idea, leading to excessive delivery

smtpd_recipient_limit=1 ? (was: Re: Tell LMTP who is original recipient?)

2019-05-21 Thread MRob
On 2019-05-21 21:47, @lbutlr wrote: On 21 May 2019, at 15:36, MRob wrote: Privacy problem is addressed with smtpd_recipient_limit=1 but thats not very feasible. Are you sure? I think even the big mailing-list services send individual messages now-a-days. I thought I remember strong opinio

Re: Tell LMTP who is original recipient?

2019-05-21 Thread @lbutlr
On 21 May 2019, at 15:36, MRob wrote: > Privacy problem is addressed with smtpd_recipient_limit=1 but thats not very > feasible. Are you sure? I think even the big mailing-list services send individual messages now-a-days. -- Good old Dame Fortune. You can _depend_ on her.

Re: Tell LMTP who is original recipient?

2019-05-21 Thread MRob
On 2019-05-21 20:22, Wietse Venema wrote: MRob: For some time it is possible to make postfix virtual tell a LDA who is the original recipient, add x-original-to header. But not LMTP. This create problems in final delivery, one example is autoreply vacation program cannot check if message was add

Re: Tell LMTP who is original recipient?

2019-05-21 Thread MRob
On 2019-05-21 18:42, MRob wrote: For some time it is possible to make postfix virtual tell a LDA who is the original recipient, add x-original-to header. But not LMTP. This create problems in final delivery, one example is autoreply vacation program cannot check if message was addressed directly

Re: Modify logs for delivery?

2019-05-21 Thread @lbutlr
On 21 May 2019, at 15:07, @lbutlr wrote: > May 21 14:52:32 mail postfix/local[63216]: 457nyS31Y4zdrvK: > to=, orig_to=, relay=local, > delay=0.39, delays=0.34/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to > command: /usr/local/bin/procmail -t -a $EXTENSION) > > May 21 14:53:16 mail postfix

Modify logs for delivery?

2019-05-21 Thread @lbutlr
I may have asked this in the past, but ion so it's been longe enough I don't remember and can't find it my mail archives. Is there some way to modify what is logged from postfix/local and postfix/pipe so that the "status=sent" lines include the from address as well as the to address? May 21 14

Re: Tell LMTP who is original recipient?

2019-05-21 Thread Wietse Venema
MRob: > For some time it is possible to make postfix virtual tell a LDA who is > the original recipient, add x-original-to header. But not LMTP. This > create problems in final delivery, one example is autoreply vacation > program cannot check if message was addressed directly to this user or >

Tell LMTP who is original recipient?

2019-05-21 Thread MRob
For some time it is possible to make postfix virtual tell a LDA who is the original recipient, add x-original-to header. But not LMTP. This create problems in final delivery, one example is autoreply vacation program cannot check if message was addressed directly to this user or not, so many au

Re: intermittent "cannot find your reverse hostname" for outbound.protection.outlook.com senders. Best workaround?

2019-05-21 Thread Wietse Venema
PGNet Dev: > > That should be safe, because the OK here cannot affect how a recipient > > will be evaluated. > > Do you have any reasonable advice as to a better approach to share? Well you can drop the initial .* and you may want to end the pattern in '$' as in /\.outbound\.protection\.outl

Re: intermittent "cannot find your reverse hostname" for outbound.protection.outlook.com senders. Best workaround?

2019-05-21 Thread PGNet Dev
That should be safe, because the OK here cannot affect how a recipient will be evaluated. Do you have any reasonable advice as to a better approach to share?

Re: intermittent "cannot find your reverse hostname" for outbound.protection.outlook.com senders. Best workaround?

2019-05-21 Thread Wietse Venema
PGNet Dev: > currently, my config does include > > smtpd_helo_required = yes > smtpd_helo_restrictions = > permit_mynetworks > check_helo_access pcre:${config_directory}/helo_access.pcre > reject_invalid_helo_hostname > reject_non_fqdn_helo_hostname > permit > > is adding

Re: intermittent "cannot find your reverse hostname" for outbound.protection.outlook.com senders. Best workaround?

2019-05-21 Thread PGNet Dev
currently, my config does include smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks check_helo_access pcre:${config_directory}/helo_access.pcre reject_invalid_helo_hostname reject_non_fqdn_helo_hostname permit is adding to head of helo_access.pcre /.*\.out

intermittent "cannot find your reverse hostname" for outbound.protection.outlook.com senders. Best workaround?

2019-05-21 Thread PGNet Dev
I run postfix 3.4.5. I typically reject on unknown reverse hostname; it's a policy I'm comfortable with. For a number of correspondents that use outlook.com for outbound, I occasionally see failures crop up for the same sender, then just 'automagically' resolve. E.g., for a single sender, her

Re: SNI support

2019-05-21 Thread Bill Cole
On 21 May 2019, at 8:46, post...@io-labs.com wrote: Oh, ok. So it is reassuring in a way, means that feature is there. I might have overlooked but i found no information in documentations about how to setup the SNI support. Is it also a part that is not yet updated? There is information in

Re: SNI support

2019-05-21 Thread Wietse Venema
post...@io-labs.com: > Oh, ok. So it is reassuring in a way, means that feature is there. > I might have overlooked but i found no information in documentations > about how to setup the SNI support. Is it also a part that is not > yet updated? > Thanks. Possible search strategy: look for 'sni' in

Re: SNI support

2019-05-21 Thread postfix
Wietse Venema wrote .. > Fred Barachant: > > Hi. > > > > SNI support for smtp server and client is said to be there, from > > what i read in release notes from 3.4.0. ( > > http://www.postfix.org/announcements/postfix-3.4.0.html ) However, > > docs still say that it is not done not planned ( > >