Re: smtp_sasl_auth_enable Being Ignored

> On 2014-01-30 00:08, Noel Jones wrote: >> 250-8 BITMIME > > should it not be 8BITMIME? ask yahoo, it's their server

Re: sender domaion restrict to defined recipient

thanks for reply. Yes i want to a...@domain.com receive all email except from specific sender domain or sender address. I have already read http://www.postfix.org/RESTRICTION_CLASS_README.html but i haven't success to implement this. 2014-01-29 Wietse Venema > LuKreme: > > > > On 29 Jan 2014

Re: sender domaion restrict to defined recipient

Instead of relying on postfix, perhaps create a procmail recipe for a...@domain.com For example: :0: * ^From.*sender@foo\.bar /dev/null # default :0: /var/mail/A -- Matthew Lanfeust troy wrote: thanks for reply. Yes i want to a...@domain.com receive all email excep

Re: smtp_sasl_auth_enable Being Ignored

Viktor Dukhovni: > On Wed, Jan 29, 2014 at 09:42:00PM -0500, Wietse Venema wrote: > > > > If postconf(1) is the same version of Postfix as smtp(8), then you > > > check with "postconf smtp_tls_loglevel". This parameter is not > > > defined when TLS support is not available. > > > > All TLS (and

Re: smtp_sasl_auth_enable Being Ignored

On 29 Jan 2014, at 15:57 , li...@rhsoft.net wrote: > in mordern setups only port 587 (submission) should be used for > send authenticated mails and if someone can do that (we can't > because too many client configurations out of control) someone > could disable authentication on port 25 completly

Re: smtp_sasl_auth_enable Being Ignored

On 1/29/2014 9:17 PM, Viktor Dukhovni wrote: > On Wed, Jan 29, 2014 at 08:20:44PM -0500, Dennis Putnam wrote: > >>> The only other thing that comes to mind is that your "upgrade" may >>> have installed a version of Postfix with no TLS support. Then none >>> of these settings matter. >> Hmmm. I had

Re: smtp_sasl_auth_enable Being Ignored

On 1/29/2014 9:42 PM, Wietse Venema wrote: > Viktor Dukhovni: >> On Wed, Jan 29, 2014 at 08:20:44PM -0500, Dennis Putnam wrote: >> The only other thing that comes to mind is that your "upgrade" may have installed a version of Postfix with no TLS support. Then none of these settings

Re: smtp_sasl_auth_enable Being Ignored

On 1/29/2014 10:32 PM, Viktor Dukhovni wrote: > On Wed, Jan 29, 2014 at 09:42:00PM -0500, Wietse Venema wrote: > >>> If postconf(1) is the same version of Postfix as smtp(8), then you >>> check with "postconf smtp_tls_loglevel". This parameter is not >>> defined when TLS support is not available.

Re: smtp_sasl_auth_enable Being Ignored

Am 30.01.2014 14:30, schrieb Dennis Putnam: > On 1/29/2014 9:17 PM, Viktor Dukhovni wrote: >> On Wed, Jan 29, 2014 at 08:20:44PM -0500, Dennis Putnam wrote: >> The only other thing that comes to mind is that your "upgrade" may have installed a version of Postfix with no TLS support. Then

Re: smtp_sasl_auth_enable Being Ignored

On 1/30/2014 8:49 AM, li...@rhsoft.net wrote: > Am 30.01.2014 14:30, schrieb Dennis Putnam: >> On 1/29/2014 9:17 PM, Viktor Dukhovni wrote: >>> On Wed, Jan 29, 2014 at 08:20:44PM -0500, Dennis Putnam wrote: >>> > The only other thing that comes to mind is that your "upgrade" may > have inst

Re: sender domaion restrict to defined recipient

if we have only this solution why not. But we manage a lot of recipient and a lot of domain so it's not friendly user to manage this by procmail recipe. 2014-01-30 Matthew McGehrin : > Instead of relying on postfix, perhaps create a procmail recipe for > a...@domain.com > > For example: > > :0:

Re: smtp_sasl_auth_enable Being Ignored

Am 30.01.2014 15:00, schrieb Dennis Putnam: > On 1/30/2014 8:49 AM, li...@rhsoft.net wrote: >> Am 30.01.2014 14:30, schrieb Dennis Putnam: >>> On 1/29/2014 9:17 PM, Viktor Dukhovni wrote: On Wed, Jan 29, 2014 at 08:20:44PM -0500, Dennis Putnam wrote: >> The only other thing that com

Re: smtp_sasl_auth_enable Being Ignored

On 1/30/2014 9:10 AM, li...@rhsoft.net wrote: > > Am 30.01.2014 15:00, schrieb Dennis Putnam: >> I changed the loglevel to 1. I am not sure where or what I am supposed >> to see but the normal maillog contained nothing different. > lines like while connect to the destination > > Jan 27 19:16:17 mai

Re: smtp_sasl_auth_enable Being Ignored

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/30/2014 8:18 AM, Dennis Putnam wrote: > On 1/30/2014 9:10 AM, li...@rhsoft.net wrote: >> >> Am 30.01.2014 15:00, schrieb Dennis Putnam: >>> I changed the loglevel to 1. I am not sure where or what I >>> am supposed to see but the normal maillog c

Re: smtp_sasl_auth_enable Being Ignored

smtp.att.yahoo.com[98.139.221.42]:587: 220 smtp.att.yahoo.com ESMTP ready smtp.att.yahoo.com[98.139.221.42]:587: EHLO home.bellsouth.net smtp.att.yahoo.com[98.139.221.42]:587: 250-smtp.att.yahoo.com smtp.att.yahoo.com[98.139.221.42]:587: 250-PIPELINING smtp.att.yahoo.com[98.139.221.42]:587: 25

Re: smtp_sasl_auth_enable Being Ignored

On 1/30/2014 9:34 AM, Noel Jones wrote: > > > I changed the level to 2. I am not seeing what you suggest but > > there is one additional line initializing TLS engine. Here is > > the output: > > > ... useless debug output deleted > > > > To repeat my previous question, is there no way to force a >

Re: smtp_sasl_auth_enable Being Ignored

Am 30.01.2014 15:51, schrieb Dennis Putnam: > Thanks for your patience but why wouldn't the working server also be failing > if TLS was indeed screwed up? because he does not force TLS > Here is the postconf -n output: snipped > In case it is needed here is the content of tls_policy: > > in

Re: smtp_sasl_auth_enable Being Ignored

On 1/30/2014 8:59 AM, li...@rhsoft.net wrote: > > > Am 30.01.2014 15:51, schrieb Dennis Putnam: >> Thanks for your patience but why wouldn't the working server also be failing >> if TLS was indeed screwed up? > > because he does not force TLS > >> Here is the postconf -n output: > > snipped >

Re: smtp_sasl_auth_enable Being Ignored

Am 30.01.2014 15:59, schrieb li...@rhsoft.net: > Am 30.01.2014 15:51, schrieb Dennis Putnam: >> Thanks for your patience but why wouldn't the working server also be failing >> if TLS was indeed screwed up? > > because he does not force TLS > >> Here is the postconf -n output: > > snipped > >

Re: smtp_sasl_auth_enable Being Ignored

On 1/30/2014 9:59 AM, li...@rhsoft.net wrote: > > Am 30.01.2014 15:51, schrieb Dennis Putnam: >> Thanks for your patience but why wouldn't the working server also be failing >> if TLS was indeed screwed up? > because he does not force TLS > >> Here is the postconf -n output: > snipped > >> In case

Re: smtp_sasl_auth_enable Being Ignored

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/30/2014 8:51 AM, Dennis Putnam wrote: > On 1/30/2014 9:34 AM, Noel Jones wrote: >> >>> I changed the level to 2. I am not seeing what you suggest >>> but there is one additional line initializing TLS engine. >>> Here is the output: >> >> >> ...

Re: smtp_sasl_auth_enable Being Ignored

On Thu, Jan 30, 2014 at 09:51:30AM -0500, Dennis Putnam wrote: > relayhost = [smtp.att.yahoo.com]:587 > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy > > In case it is needed here is the content of tls_policy: > > in.mailjet.com may > smtp.att.yahoo.com:587 encrypt It is rather sad that

Re: generic rewriting done after opendkim

On Wed, Jan 29, 2014 at 10:06:26PM +, Viktor Dukhovni wrote: > On Wed, Jan 29, 2014 at 10:47:07PM +0100, Klavs Klavsen wrote: > > > I currently employ generic rewriting of sourceaddresses, like this: > > smtp_generic_maps = hash:/etc/postfix/generic > > regexp:/etc/postfix/generic_regexp > >

Re: ISP relay - Before queue filtering, per-domain

On Wed, 29 Jan 2014, Noel Jones wrote: I couldn't find a way to make Amavisd scan only for certain domains, rather than whitelist. (Although I understand this is beyond the scope of this list :)) Any kind of pre-queue per-domain filtering will need to be done within the filter -- once the m

Re: ISP relay - Before queue filtering, per-domain

* Duncan B. : > > > On Wed, 29 Jan 2014, Noel Jones wrote: > > >>I couldn't find a way to make Amavisd scan only for certain domains, > >>rather than whitelist. (Although I understand this is beyond the > >>scope of this list :)) > >> > > > >Any kind of pre-queue per-domain filtering will need t

Re: ISP relay - Before queue filtering, per-domain

On Thu, 30 Jan 2014, Patrick Ben Koetter wrote: I suggest you do not use the envelope-sender address, because it can be forged easily. Instead I'd use valid DKIM signatures as trigger to bypass certain checks: @author_to_policy_bank_maps = ( { 'sys4.de' => 'WHITELIST,NOBA

Re: ISP relay - Before queue filtering, per-domain

On 1/30/2014 9:53 AM, Duncan B. wrote: > > > On Thu, 30 Jan 2014, Patrick Ben Koetter wrote: > >> I suggest you do not use the envelope-sender address, because it >> can be forged >> easily. Instead I'd use valid DKIM signatures as trigger to bypass >> certain >> checks: >> >> @author_to_policy_

Error messages with mail for local users

Hello, I set postfix (see http://www.marzocchi.net/Olafsen/Software/OmniOSPostfixAndStunnel ) and it seems it works well, that means I can send mail from the terminal and I will get it correctly when I specify a complete address, and the same applies to daemons that accept as parameter an email

Configuring SASL PLAIN auth only after STARTTLS

Hi list, I have a Postfix setup with Dovecot SASL. Other MTAs drop their mail at my host (without authentication obviously) and I have a couple of clients which drop their relay mail off after authentication. So, a pretty standard setup. For SASL authentication I have hashed passwords in the back

Re: Configuring SASL PLAIN auth only after STARTTLS

On Fri, Jan 31, 2014 at 12:54:01AM +0100, Johannes Bauer wrote: > What I would like to do and cannot figure out: How can I *force* > authenticated clients to perform a STARTTLS before performing a "AUTH > PLAIN"? If plaintext mechanisms are all you have: smtpd_tls_auth_only = yes This disab

Re: Configuring SASL PLAIN auth only after STARTTLS

On 31.01.2014 01:41, Viktor Dukhovni wrote: > On Fri, Jan 31, 2014 at 12:54:01AM +0100, Johannes Bauer wrote: > >> What I would like to do and cannot figure out: How can I *force* >> authenticated clients to perform a STARTTLS before performing a "AUTH >> PLAIN"? > > If plaintext mechanisms are a

are these 'good and reliable' adls/dynamic pcre rejects?

my pre configured Postfix inluded these helo_access.pcre rejects; today, I noticed an expected email was bounced by one of the pre-configured rules as so: Jan 31 10:08:01 emu postfix/smtpd[11075]: NOQUEUE: reject: RCPT from unknown[59.167.231.218]: 554 5.7.1 : Helo command rejected: Go away, bad

Re: Configuring SASL PLAIN auth only after STARTTLS

On Fri, Jan 31, 2014 at 02:07:51AM +0100, Johannes Bauer wrote: > On 31.01.2014 01:41, Viktor Dukhovni wrote: > > On Fri, Jan 31, 2014 at 12:54:01AM +0100, Johannes Bauer wrote: > > > >> What I would like to do and cannot figure out: How can I *force* > >> authenticated clients to perform a START

Re: are these 'good and reliable' adls/dynamic pcre rejects?

On 1/30/2014 7:17 PM, li...@sbt.net.au wrote: > my pre configured Postfix inluded these helo_access.pcre rejects; > > today, I noticed an expected email was bounced by one of the > pre-configured rules as so: > > Jan 31 10:08:01 emu postfix/smtpd[11075]: NOQUEUE: reject: RCPT from > unknown[59.16