Re: Postscreen Feature Request

On 03/09/17 00:43, Wietse Venema wrote: > On 02/09/17 22:03, Wietse Venema wrote: >> Surprise: I already solved that problem: postscreen would hand off >> the _decrypted_ session to the tarpitting daemon :-) > > Allen Coates: >> How would you optionally hand off to the tarpit daemon, instead of

Re: Postscreen Feature Request

On 02/09/17 22:03, Wietse Venema wrote: > Surprise: I already solved that problem: postscreen would hand off > the _decrypted_ session to the tarpitting daemon :-) Allen Coates: > How would you optionally hand off to the tarpit daemon, instead of to > postfix? That requires new code for a config

Re: Postscreen Feature Request

On 02/09/17 22:03, Wietse Venema wrote: > > Surprise: I already solved that problem: postscreen would hand off > the _decrypted_ session to the tarpitting daemon :-) > How would you optionally hand off to the tarpit daemon, instead of to postfix? Allen C

Re: will master.cf inherit parameters from main.cf

xiedeacc: > will master.cf inherit parameters from main.cf ? like > smptd_recipient_restrictions, I found I cannot set > smptd_recipient_restrictions=check_recipient_access > hash:/etc/postfix/recipient_access, it complaint fatal: > unexpected command-line argument: hash:/etc. > master.cf

Re: Postscreen Feature Request

Viktor Dukhovni: > On Sat, Sep 02, 2017 at 09:01:21AM -0400, Wietse Venema wrote: > > Allen Coates: > > > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the > > > decision to reject the message has already been made; > > > It seems to me that this is an opportunity to tar-pit the

Re: majordomo postfix 2.10.1 No recipient addresses found in message header

Hi, i think, i found the reason for the majordomo-problem. Problem is the Update from perl4 to perl5. I find the "$* is no longer supported at"-Message in my debug-file /var/tmp/majordomo.debug https://www.claudiokuenzler.com/blog/62/$*_is_no_longer_supported_majordomo#.War3WDdLezc

Avoiding duplicate reply-to lines in header

I have an email address that sends to five people using a virtual-map line: tinyl...@example.comm...@example.com, t...@example.com, (etc) When tinylist receives email, header_checks uses the following test to add a reply-to line to the header, so that replies go to 'tinylist' rather than

Ironic interaction of greylistiing, backup MX hosts and DANE

[ To be sent separately also to the dane-us...@sys4.de list. ] I sent a "please fix your TLSA records" notice to "postmaster" and "info" at a domain whose primary MX host certificate fails to match its TLSA records: postfix/pickup[62805]: 7672C1DD39: ... postfix/cleanup[63835]:

Re: Postscreen Feature Request

On Sat, Sep 02, 2017 at 09:01:21AM -0400, Wietse Venema wrote: > Allen Coates: > > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the > > decision to reject the message has already been made; > > It seems to me that this is an opportunity to tar-pit the (bad) remote > > host,

Re: reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied

On Sat, Sep 02, 2017 at 06:34:35AM -0700, xiedeacc wrote: Note the below reformatting of the text you sent to show one logical restrictin per line. When asking for help it is polite to make it easier for others to help you. Try to not send a jumble of text that others have to tease apart.

will master.cf inherit parameters from main.cf

will master.cf inherit parameters from main.cf ? like smptd_recipient_restrictions, I found I cannot set smptd_recipient_restrictions=check_recipient_access hash:/etc/postfix/recipient_access, it complaint fatal: unexpected command-line argument: hash:/etc. -- Sent from:

Re: reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied

thanks, I have read all those docs, and I find fix it, but after do some tries, I find out config wrong smtpd_relay_restrictions parameters , and ask another question, will master.cf inherit parameters from main.cf like smptd_recipient_restrictions? -- Sent from:

Re: reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied

xiedeacc: > Hi, all > my postfix now can send/recive mail from my own domain, and can send out > mail to external mail server like gmail, but cannot recive mail from > external mail server, mail.log said reject: RCTP from xxx 554 5.7.1 > Recipient addressd: Access denied > >

reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied

Hi, all my postfix now can send/recive mail from my own domain, and can send out mail to external mail server like gmail, but cannot recive mail from external mail server, mail.log said reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied smtpd_recipient_restrictions =

Re: Postscreen Feature Request

Allen Coates: > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the > decision to reject the message has already been made; > It seems to me that this is an opportunity to tar-pit the (bad) remote > host, diminishing spam throughput, and eroding the host's useful life-span.

Re: sasl auth LOGIN / PLAIN

On 09/02/2017 01:16 PM, Patrick Ben Koetter wrote: Mandatory STARTTLS*and* disallowing any shared-secret mechanism (CRAM-MD5, DIGEST-MD5, NTLM) is a clever move. This way you protect the identity while it is transported from the client to the server and you are able to store the passwords

Re: sasl auth LOGIN / PLAIN

* mj : > Hi, > > Ok, so disallowing LOGIN is not a clever move :-) Mandatory STARTTLS *and* disallowing any shared-secret mechanism (CRAM-MD5, DIGEST-MD5, NTLM) is a clever move. This way you protect the identity while it is transported from the client to the server and you

Postscreen Feature Request

GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the decision to reject the message has already been made; It seems to me that this is an opportunity to tar-pit the (bad) remote host, diminishing spam throughput, and eroding the host's useful life-span. I SUGGEST, therefore, that

Re: sasl auth LOGIN / PLAIN

Hi, Ok, so disallowing LOGIN is not a clever move :-) Thanks for your answers! MJ On 09/02/2017 08:32 AM, Patrick Ben Koetter wrote: * postfix : On 09/01/2017 04:25 PM, mj wrote: Just a small question: we currently use posfix with sasl authentication, and folowing many

Re: sasl auth LOGIN / PLAIN

* postfix : > On 09/01/2017 04:25 PM, mj wrote: > > Just a small question: we currently use posfix with sasl authentication, > > and folowing many docs, we have enabled PLAIN and LOGIN authentication. > > > > However, googling leads me to believe that LOGIN is mostly used by > >