Re: qmgr_queue_throttle not fired up in 2.12.20140209

On 19/02/2014 17:15, Viktor Dukhovni wrote: On Wed, Feb 19, 2014 at 03:00:25PM +0200, Birta Levente wrote: With 2.12.20140209 I get hundreds defferals because: Feb 19 05:21:59 srv2 postfix-slow/smtp[14313]: Untrusted TLS connection established to mta5.am0.yahoodns.net[98.138.112.38]:25: TLSv1

[no subject]

Hello Since I activated SMTP TLS ( client and server = may ) on our mail gateway I have this message in maillog Untrusted TLS connection established to ASPMX.L.GOOGLE.COM[173.194.66.27]:25: TLSv1 with cipher RC4-SHA (128/128 bits) any info ? thank you

Re: next time write a subject

Am 21.02.2014 11:37, schrieb BONNET, Frank: > Since I activated SMTP TLS ( client and server = may ) on our mail gateway I > have this message in maillog > > Untrusted TLS connection established to ASPMX.L.GOOGLE.COM > [173.194.66.27]:25: TLSv1 > with cipher RC4-SHA

Re:

Am 21.02.2014 11:37, schrieb BONNET, Frank: > Hello > > Since I activated SMTP TLS ( client and server = may ) on our mail > gateway I have this message in maillog > > Untrusted TLS connection established to ASPMX.L.GOOGLE.COM > [173.194.66.27]:25: TLSv1 with cipher RC

Re:

Am 21.02.2014 11:58, schrieb Robert Schetterer: > Am 21.02.2014 11:37, schrieb BONNET, Frank: >> Hello >> >> Since I activated SMTP TLS ( client and server = may ) on our mail >> gateway I have this message in maillog >> >> Untrusted TLS connection established to ASPMX.L.GOOGLE.COM >>

Re: your mail

* BONNET, Frank : > Hello > > Since I activated SMTP TLS ( client and server = may ) on our mail gateway > I have this message in maillog > > Untrusted TLS connection established to ASPMX.L.GOOGLE.COM[173.194.66.27]:25: > TLSv1 with cipher RC4-SHA (128/128 bits) Your smtp client has successfuly

Re: qmgr_queue_throttle not fired up in 2.12.20140209

Birta Levente: > > plaintext retries possibily raising this to four. > > > > We had considered special-casing "4XX" replies as a reason to not > > retry plaintext when TLS connections are lost. If your more complete > > logs demonstrate a need to do that, we may add the requisite logic. > > > > Pl

Re: qmgr_queue_throttle not fired up in 2.12.20140209

Wietse Venema: > Birta Levente: > > > plaintext retries possibily raising this to four. > > > > > > We had considered special-casing "4XX" replies as a reason to not > > > retry plaintext when TLS connections are lost. If your more complete > > > logs demonstrate a need to do that, we may add the

Problem after upgrading to 2.11

I did upgrade postfix from 2.9.4 to 2.11 on my relay backup server. I use ldap table to store some information (transport, domain ). After the update I receive an error : warning: connect to transport private/ldap: No such file or directory In main.cf I have the following line : transport_maps

Re: qmgr_queue_throttle not fired up in 2.12.20140209

On 21/02/2014 13:41, Wietse Venema wrote: Birta Levente: plaintext retries possibily raising this to four. We had considered special-casing "4XX" replies as a reason to not retry plaintext when TLS connections are lost. If your more complete logs demonstrate a need to do that, we may add the r

Re: qmgr_queue_throttle not fired up in 2.12.20140209

Wietse Venema: The behavior that you seem to prefer (throttle down domains after 4XX reply to "MAIL FROM") is really a bug in the Postfix SMTP client implementation. Postfix normally does not throttle down domains after 4XX reply to "MAIL FROM". The bug is that Postfix treats server-side disconne

Re: Problem after upgrading to 2.11

Vittorio Manfredini: > In main.cf I have the following line : > relay_transport = ldap:/etc/postfix/ldaptransport.cf relay_transport (default: relay) ... Specify a string of the form transport:nexthop, WHERE TRANSPORT IS THE NAME OF A MAIL DELIVERY TRANSPORT DEFINED IN MASTER.CF. ...

Re: qmgr_queue_throttle not fired up in 2.12.20140209

On 21/02/2014 15:44, Wietse Venema wrote: Wietse Venema: The behavior that you seem to prefer (throttle down domains after 4XX reply to "MAIL FROM") is really a bug in the Postfix SMTP client implementation. Postfix normally does not throttle down domains after 4XX reply to "MAIL FROM". The bug

Re: qmgr_queue_throttle not fired up in 2.12.20140209

Birta Levente: > On 21/02/2014 15:44, Wietse Venema wrote: > > The behavior that you seem to prefer (throttle down > > domains after 4XX reply to "MAIL FROM") is really a bug in the > > Postfix SMTP client implementation. > > > > Postfix normally does not throttle down domains after 4XX reply to >

need assistants off list with REGEX for amavis

greetings I need some help with a regex for amavis. I have some bulk email that keeps coming back with different domain names and subject lines but there is a pattern to the nonsense example; EmailMarketingResults-username1=mydomain@foodomain.com FreeCellPhones-username2=mydom...@foodomain

Re:

On Fri, Feb 21, 2014 at 12:04:47PM +0100, li...@rhsoft.net wrote: > smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt That's a waste of CPU. Leaving it empty is better. No false sense of security. If you're making "secure-channel" connection to selected destinations, then you need appropriate

Check Feader in multiple condition

Hi I want to use Header_Checks file in reject email selected from multiple line criteria. For example I want to reject only email which has to: fiels x...@.tld but only From: z...@ccc.tld In Header_check file: /^From:z...@ccc.tld/ REEJECT IF ONLY BUT to: field is x...@.tl

Re: Check Feader in multiple condition

Gaby L: > Hi > > I want to use Header_Checks file in reject email selected from > multiple line criteria. As documented this is not possible. Use a real content filter. Wietse

Re: Check Feader in multiple condition

this should be possible by defining another smtpd service with a separate cleanup process (which will have its own header check) first header check ( To = x...@.tld ) filter---> smtpd:port --- second header check (From = z...@ccc.tld ) can be done using following configuration: first hea

Re: Check Feader in multiple condition

On Sat, Feb 22, 2014 at 01:01:25AM +0530, Indrajeet Kumar wrote: > this should be possible by defining another smtpd service with a separate > cleanup process (which will have its own header check) > first header check ( To = x...@.tld ) filter---> smtpd:port --- > second header check (Fro