Re: [exim] Segfault in 4.86 (mail queue handleing)

> On 6/10/2015, at 2:52 am, Heiko Schlittermann wrote: > > The +fixes branch was invented to provide fast access to the most > important subset of changes without the need for new release. > > But you're right, if the urgency for (some of) the patches rises, we > should

[exim] Fw: what is log part ? attack ?

Bingo !!! Thanks Graeme !!! I deleted yahoo.nl domain from the blacklist is everything will back correct. There should be only suffix domains in blacklists ? eg. *.ru czarnalista is english balcklist "Tych klientów nie obsługujemy" is english "These clients do not support" processing "deny"

[exim] RES: filter based on content

Can you clarify more this? -Mensagem original- De: Exim-users [mailto:exim-users-bounces+wilson.galafassi=gmail@exim.org] Em nome de Jeremy Harris Enviada em: sábado, 10 de outubro de 2015 08:12 Para: exim-users@exim.org Assunto: Re: [exim] filter based on content On 09/10/15 22:08,

Re: [exim] RES: filter based on content

On 13 Oct 2015, at 14:39, Wilson A. Galafassi Jr. [Gmail] wrote: > Can you clarify more this? After Jeremy said: > Depends to a large extent on what cpanel offers. What Jeremy means is - it's very likely possible, but it depends on the way cPanel specifically

[exim] tls_tempfail_tryclear and "delivery in clear" on no-TLS-support only and not cipher/protocol failure

Hi, coming from postfix, it is (to me) impossible to setup a mechanism which will attempt a "delivery in clear", ONLY if there is truly no TLS support present and not when cipher/protocol is simply failing/missing. How can it be done? Thanks and best regards, fe

[exim] Historic Source Code

Hi, I'm thinking of doing an essay for a school project on the Exim MTA. I was wondering if there were any version control repositories that contain history of exim prior to 2004 I can clone the github repo, but it would be interesting to look at code and version changes prior to that.

Re: [exim] verification of Rdns

> From: Jim Pazarena > > I use exim to verify rdns. > It occasionally determines a failure which I cannot 'prove'. > Not with nslookup. not with dig. It's why in case of empty $sender_host_name instead of rejection I use greylisting. More exactly, I use selective greylisting - only if something

Re: [exim] Historic Source Code

On 12/10/15 12:05, Kate Dawson wrote: > Hi, > > I'm thinking of doing an essay for a school project on the Exim MTA. > > I was wondering if there were any version control repositories that > contain history of exim prior to 2004 > > I can clone the github repo, but it would be interesting to

Re: [exim] Historic Source Code

Some years ago (around August 2007 it appears) I had an opportunity to get copies of old exim releases. I have no memory of why, maybe they were going to be dumped during a server move, or maybe someone asked about them like you have done and I jumped on it too. Anyway, I still have it. No SVN,

Re: [exim] tls_tempfail_tryclear and "delivery in clear" on no-TLS-support only and not cipher/protocol failure

On 13/10/15 16:07, Viktor Dukhovni wrote: > On Mon, Oct 12, 2015 at 01:19:07PM +0200, Felix Engel wrote: > >> Hi, >> >> coming from postfix, it is (to me) impossible to setup >> a mechanism which will attempt a "delivery in clear", >> ONLY if there is truly no TLS support present and not >>

Re: [exim] tls_tempfail_tryclear and "delivery in clear" on no-TLS-support only and not cipher/protocol failure

On Mon, Oct 12, 2015 at 01:19:07PM +0200, Felix Engel wrote: > Hi, > > coming from postfix, it is (to me) impossible to setup > a mechanism which will attempt a "delivery in clear", > ONLY if there is truly no TLS support present and not > when cipher/protocol is simply failing/missing. > >

Re: [exim] tls_tempfail_tryclear and "delivery in clear" on no-TLS-support only and not cipher/protocol failure

On 12/10/15 12:19, Felix Engel wrote: > Hi, > > coming from postfix, it is (to me) impossible to setup > a mechanism which will attempt a "delivery in clear", > ONLY if there is truly no TLS support present Hmm. I think you'll have to very clear define, down to the protocol level, what you're

Re: [exim] tls_tempfail_tryclear and "delivery in clear" on no-TLS-support only and not cipher/protocol failure

On Mon, Oct 12, 2015 at 01:19:07PM +0200, Felix Engel wrote: > coming from postfix, it is (to me) impossible to setup > a mechanism which will attempt a "delivery in clear", > ONLY if there is truly no TLS support present and not > when cipher/protocol is simply failing/missing. > > How can it

Re: [exim] tls_tempfail_tryclear and "delivery in clear" on no-TLS-support only and not cipher/protocol failure

On Tue, Oct 13, 2015 at 04:18:22PM +0100, Jeremy Harris wrote: > > Nowhere in the above list is there a mode that avoids cleartext > > fallback when "STARTTLS" is offered, but the handshake or data > > transmission fails. We've been thinking about adding parameters > > that tweak "may" in that

[exim] RES: RES: filter based on content

Hi, Cpanel told me that if change something in the default configuration i have to follow this: https://documentation.cpanel.net/display/ALD/Customize+the+Exim+System+Filter+File#CustomizetheEximSystemFilterFile-Howtocreateacustomfilterrulefile to avoid lost the changes after the nightly

Re: [exim] Historic Source Code

On 13 Oct 2015, at 15:47, John Jetmore wrote: > Anyway, I still have it. No SVN, but releases for Exim 1, 2, 3, and 4, > starting with 1.62. I suspect strongly that there're some releases > missing, but it's more than I've seen anywhere else. You're welcome to a > copy if you