Matt Sergeant wrote:
>
> I'm thinking more on the lines of pushing back reads if they're not full
> lines.
>
> Probably needs a bit of support for that in lib/Danga/Client.pm
Attached is an attempt to do that. The reason for this is that I've seen
another case of end of data marker coming in t
Radu Greab skribis 2008-04-14 22:19 (+0300):
> $data =~ s/\r\n\.\r\n(.*)\z/\r\n/ms
If you don't want to use the regex engine (and indeed, especially
regexes with .* are often inefficient), you could use good old index and
substr to achieve the same:
# untested code
my $data_end = index(
Matt Sergeant wrote:
>
> >> I can't help feeling there's a better way to do it - I hate applying
> >> two
> >> regexps every time a DATA packet comes in... I'll have a think on
> >> it.
One option could be to keep this regexp
$data =~ s/\r\n\.\r\n(.*)\z/\r\n/ms
and, if it is not matched, the
On Mon, 14 Apr 2008, Guy Hulbert wrote:
On Mon, 2008-14-04 at 12:54 +, Matt Sergeant wrote:
Attached are a test script and a suggested patch.
I committed the patch 95% the same as yours.
I can't help feeling there's a better way to do it - I hate applying
two
regexps every time a DATA pa
On Mon, 2008-14-04 at 12:54 +, Matt Sergeant wrote:
> > Attached are a test script and a suggested patch.
>
> I committed the patch 95% the same as yours.
>
> I can't help feeling there's a better way to do it - I hate applying
> two
> regexps every time a DATA packet comes in... I'll have a
On Sat, 12 Apr 2008, Radu Greab wrote:
I found a case where qpsmtpd-async detects the end of data marker
incorrectly: the previous packet did not end with CRLF and the current
packet starts with .CRLF. The code assumes that the previous packet
ended with CRLF.
Attached are a test script and a
On Mon, 14 Apr 2008, Matt Sergeant wrote:
On Sat, 12 Apr 2008, Radu Greab wrote:
I found a case where qpsmtpd-async detects the end of data marker
incorrectly: the previous packet did not end with CRLF and the current
packet starts with .CRLF. The code assumes that the previous packet
ended w
On Sat, 12 Apr 2008, Radu Greab wrote:
I found a case where qpsmtpd-async detects the end of data marker
incorrectly: the previous packet did not end with CRLF and the current
packet starts with .CRLF. The code assumes that the previous packet
ended with CRLF.
Attached are a test script and a
Radu Greab wrote:
>
>
> Matt Sergeant wrote:
> >
> > Though I could have sworn I fixed this - are you sure you're testing
> > against latest SVN?
>
> I do not have the latest SVN in production. I have 0.43rc1 with
> additional patches, including your change #129 which, I think, is what
> you
Matt Sergeant wrote:
>
> Though I could have sworn I fixed this - are you sure you're testing
> against latest SVN?
Hi,
I do not have the latest SVN in production. I have 0.43rc1 with
additional patches, including your change #129 which, I think, is what
you are referring to as having fixed th
Ask Bjørn Hansen wrote:
On Apr 12, 2008, at 6:33, Radu Greab wrote:
I found a case where qpsmtpd-async detects the end of data marker
incorrectly: the previous packet did not end with CRLF and the current
packet starts with .CRLF. The code assumes that the previous packet
ended with CRLF.
Hi
On Apr 12, 2008, at 6:33, Radu Greab wrote:
I found a case where qpsmtpd-async detects the end of data marker
incorrectly: the previous packet did not end with CRLF and the current
packet starts with .CRLF. The code assumes that the previous packet
ended with CRLF.
Hi Radu,
Can you add it to
I found a case where qpsmtpd-async detects the end of data marker
incorrectly: the previous packet did not end with CRLF and the current
packet starts with .CRLF. The code assumes that the previous packet
ended with CRLF.
Attached are a test script and a suggested patch.
Thanks,
Radu Greab
#!/
13 matches
Mail list logo
