Re: [exim] Line length RFC issues

2020-01-16 Thread Viktor Dukhovni via Exim-users
On Thu, Jan 16, 2020 at 10:56:08PM -0500, John C Klensin wrote: > However, 5321 also makes it very clear that SMTP-conformant > servers are not supposed to be tampering with message payloads > (everything that follows the DATA command up to the "." CRLF, > often called "content", but I'm trying to

Re: [exim] Line length RFC issues

2020-01-16 Thread John C Klensin via Exim-users
--On Thursday, January 16, 2020 16:40 -0500 Viktor Dukhovni via Exim-users wrote: > We'll have to disagree on this, because given non-conformant > (with RFC5322 Section 2.1.1) input we're free to do whatever > is reasonably pragmatic and yields a conformant message for > delivery to the next h

Re: [exim] Line length RFC issues

2020-01-16 Thread Viktor Dukhovni via Exim-users
We'll have to disagree on this, because given non-conformant (with RFC5322 Section 2.1.1) input we're free to do whatever is reasonably pragmatic and yields a conformant message for delivery to the next hop. Perhaps not surprisingly, users preferred delivery over bounces. > On Jan 16, 2020, at 4:

Re: [exim] Line length RFC issues

2020-01-16 Thread John C Klensin via Exim-users
Of course, Postfix is out of conformance with the standard and, maybe more important, breaking any signatures over the message body text, by doing this. Basically you can't win. And that requirement is in the standard, not only because of the historical reason of some implementations needing to a

Re: [exim] Line length RFC issues

2020-01-16 Thread Viktor Dukhovni via Exim-users
> On Jan 16, 2020, at 1:12 PM, Jeremy Harris via Exim-users > wrote: > >> Does anyone know of anything that Exim can do to modify the message as >> it is routed through > > Exim can't; it's a policy decision in what it regards it's job > as being. That covers things like not converting from 8-

Re: [exim] Line length RFC issues

2020-01-16 Thread Jeremy Harris via Exim-users
On 16/01/2020 17:40, Paul Tansom via Exim-users wrote: > Does anyone know of anything that Exim can do to modify the message as > it is routed through Exim can't; it's a policy decision in what it regards it's job as being. That covers things like not converting from 8-bit-dirty to uuencoded, and

Re: [exim] Tainting & rewrite rules

2020-01-16 Thread Jeremy Harris via Exim-users
On 16/01/2020 17:42, Ian Zimmerman via Exim-users wrote: > Looking at this, I see there is no longer a way to disable the > optimization completely at compile-time (ie. -DTAINT_CHECK_SLOW). May I > respectfully request that it be added back? You can ask, but a justification would help! -- Cheers

[exim] Line length RFC issues

2020-01-16 Thread Paul Tansom via Exim-users
I've sorted out the specific Exim configuration changes for this, but it hasn't completely sorted out the problem, so in the hope (all be it small) that there is something else I can do with Exim to help, or given that this is likely a place where people will be familiar with the issue I thought I'

Re: [exim] Tainting & rewrite rules

2020-01-16 Thread Ian Zimmerman via Exim-users
On 2020-01-16 16:00, Jeremy Harris wrote: > I'm going for the alternate method of checking at runtime. > See 36eb5d3d77. Looking at this, I see there is no longer a way to disable the optimization completely at compile-time (ie. -DTAINT_CHECK_SLOW). May I respectfully request that it be added ba

Re: [exim] Tainting & rewrite rules

2020-01-16 Thread Jeremy Harris via Exim-users
On 16/01/2020 15:33, Andreas Metzler via Exim-users wrote: > Jeremy Harris via Exim-users wrote: >> On 13/01/2020 14:02, Evgeniy Berdnikov via Exim-users wrote: >>> debian package exim4-daemon-heavy_4.93-5_i386. > >> ooh - 32-bit? I wonder if the address-space layout is >> different enough to

Re: [exim] Tainting & rewrite rules

2020-01-16 Thread Andreas Metzler via Exim-users
Jeremy Harris via Exim-users wrote: > On 13/01/2020 14:02, Evgeniy Berdnikov via Exim-users wrote: >> debian package exim4-daemon-heavy_4.93-5_i386. > ooh - 32-bit? I wonder if the address-space layout is > different enough to invalidate the assumptions made by > the Linux makefiles, for taint

Re: [exim] Tainting & rewrite rules

2020-01-16 Thread Evgeniy Berdnikov via Exim-users
On Thu, Jan 16, 2020 at 11:05:47AM +, Jeremy Harris via Exim-users wrote: > On 16/01/2020 10:30, Evgeniy Berdnikov via Exim-users wrote: > > Maybe some variation of this approach have chances to survive, say, > > special pools with "untainted" strings and special functions to put > > a strin

Re: [exim] Tainting & rewrite rules

2020-01-16 Thread Jeremy Harris via Exim-users
On 16/01/2020 10:30, Evgeniy Berdnikov via Exim-users wrote: > However, the assumption that malloc() and its derivative functions use > only sbrk(2) is too optimistic. :-) And it is definitely wrong for > glibc-based implementations, including Linux, where "man malloc" says: > >Normally, ma

Re: [exim] Tainting & rewrite rules

2020-01-16 Thread Evgeniy Berdnikov via Exim-users
Hello. On Mon, Jan 13, 2020 at 11:50:59PM +, Jeremy Harris via Exim-users wrote: > On 13/01/2020 18:46, Evgeniy Berdnikov via Exim-users wrote: > > Surprised that tainting mechanizm requires some knowledge about > > address space mapping or RTL internals. I'd expect "tainting" to be > >