Alexander,
> Done and it works, so it's a perl bug (since I used the same distro
> with the same C libs). Maybe I'll add a bug report to debian's perl
> page. Thx for the help, was very insightful!
Thanks for your persistence too!
Mark
-
Hi Mark,
> I'll download perl, compile it, use CPAN to download all modules and
> redirect amavisd-new to the new perl binary.
> Not sure when I'm done.
Done and it works, so it's a perl bug (since I used the same distro
with the same C libs). Maybe I'll add a bug report to debian's perl
page
Hi Mark,
> croak("$cmd: UNICODE DATA to syswrite") if utf8::is_utf8($line);
Didn't die.
> Alternatively, you may try replacing syswrite() in Net::Cmd::datasend
> by send() or print.
Didn't work, well I had to do something with substr to get the same
effekt which resulted first in some odd dis
Alexander,
One more idea to test - whether Net::Cmd gets octets or characters:
--- Cmd.pm~ Wed Jun 30 15:56:11 2004
+++ Cmd.pm Tue Aug 22 16:14:24 2006
@@ -434,4 +434,5 @@
if (select(undef,$wout=$win, undef, $timeout) > 0 or -f $cmd) # -f for
testing on win32
{
+ croak("$cm
Alexander,
> > smtp-sink comes with Postfix
>
> Im tired but I got my proof! I give in ISO and get out Unicode!
> $smtp->datasend("ae:$ae:oe:$oe:ue:$ue\n");
Nice proof, naughty Perl584/Net::Cmd/syswrite !
Perhaps it's time to upgrade Perl to 5.8.8 and see if the problem persists,
before investin
Alexander,
> > Could you please add a line:
> > use warnings FATAL => 'utf8';
> > to every __DATA__ section in amavisd - it may catch
> > a conversion problem which could otherwise be only
> > reported to STDERR and not noticed.
> No errors. I hate those bugs that say they arn't there.
Thanks.
Alexander Schäfer,
> It worked as you described, no problem with that one liner.
> I then encapsulated your while loop (inside amavid-new) for Net::SMTP-
> datasend and put a copy of the data to a new file, guess what that
> worked too.. so I think the conversion happens inside Net::SMTP. So I
> w
Hi Mark,
> Could you please add a line:
> use warnings FATAL => 'utf8';
> to every __DATA__ section in amavisd - it may catch
> a conversion problem which could otherwise be only
> reported to STDERR and not noticed.
>
> The appatched patch does it for amavisd 2.4.2.
> With 2.3.3 it would be ana
Hi Mark,
> This one-liner is pretty much equivalent of what is going on within
> amavisd:
>
> perl -MIO::File -e '$f=IO::File->new("0.lis","+>",0640) or die $!;
> printf("%s\n",join(",",PerlIO::get_layers($f))); print $f "\344
> \366\374\n";
> $f->flush or die $!; $f->seek(0,0) or die $!; $
Alexander,
> > +binmode($self->{fh_pers}, ":bytes")
> That didn't help (even for 2.4.2). As email.txt seems to be correct,
> is there another way for amavisd-new to return the email.txt? If I
> understood the source correctly the filehandle gets passed around
> (lost count after some time),
Y
Hi Mark,
>> as expected (by you) the email.txt file is correctly encoded (meaning
>> unchanged). However in the tcpdump you clearly see that the file
>> returned in not the same file that comes in. I hope you (or someone
>> else) can give me some more tipps on debugging with the help of the
>> deb
Alexander,
> I knew something was missing, thx I added the option so my tcpdump
> call looks like this:
> "tcpdump -i any -s 0 -w tcdump.raw port 10024 or port 10025"
> I updated the uploaded tcpdump onto my webspace at www.temporal.ch/tmp .
> ... you can find three new files now, debug_sender.log
hi Mark,
> Thanks, but you packet capture truncated packets to 96 bytes.
> To see anything useful full packets need to be captured, usually
> option -s 0 to tcpdump does that, or use -s 1600.
I knew something was missing, thx I added the option so my tcpdump
call looks like this:
"tcpdump -i any
Alexander,
> Ok, but can't it be possible that the whole message gets UTF8
> encoded, since the header is ASCII anyway the problems occur only on
> the body.
Maybe some perl magic, but I haven't seen anything like that so far.
Also, amavisd sets its temporary file to binmode.
> I added a tcpdump
Hi Mark,
> amavisd-new doesn't do this, even if it wanted to.
> The mail contents gets read from a temporary file directly
> to a SMTP session back to MTA, no modifications to a mail body there.
Ok, but can't it be possible that the whole message gets UTF8
encoded, since the header is ASCII anyw
Alexander,
> I got a serious problem with Unicode and Amavis. I'm trying to solve a
> certain problem for about a week, but the problem seems to have been there
> since the first mailserver setup last year. All mail bodies seem to get
> encoded to utf-8, even if explicit not allowed to do so. iso-
Greetings from Switzerland,
I got a serious problem with Unicode and Amavis. I'm trying to solve a certain
problem for about a week, but the problem seems to have been there since the
first mailserver setup last year. All mail bodies seem to get encoded to utf-8,
even if explicit not allowed to
17 matches
Mail list logo