[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qmail-ldap
Subject:    Q: qmail-ldap and RFC-1652
From:       "Philipp Kolloczek" <kollo-qmail () muenster ! de>
Date:       2008-10-28 12:42:36
Message-ID: 002501c938fa$a9480a60$fbd81f20$ () de
[Download RAW message or body]

Hello.

Randomly i came in contact with the question how qmail-ldap handles
RFC 1652. Even if we havend't had any problems with mime coded mails
so far, this question remains to me.

As far as I found information about this qmail and with it qmail-ldap
offers on an ehlo command the 8BITMIME ( 8bit-MIMEtransport ) extension
and seems to accept the extended "mail from" command.

Additional it is found that qmail does no conversion from 8Bit to
7Bit if it hits a non 8BITMIME server but just pipes the 8bit as is.

Is this still the behavoir of qmail-ldap also?
Or is there a patch which will fix that?

Ok, in our days nearly all but "extra" configured MTA should be
able use and present the 8BITMIME-extension, but as some
small business MTAs tend to have courious configs and maybe reject 8Bit
content in DATA with out using the 8BITMIME extention it seems to me as 
a good idea to have qmail-ldap as good as possible in the RFCs.
Even if it means just to bounce a mail if the target MTA does not offer
8BITMIME.

In the code of pure qmail-ldap (qmail-remote.c) I have found nothing 
about converting 8Bit to 7Bit, in addition the "bounce 8bit as 7bit" 
(qmail-send.c) seems to be in as the pure qmail state.

On the other hand, not doing conversion won't risk any "conversion attack".
This, as qmail is, will leave the task to properly encode a mail to the
client, as 7bit, quoted-printable, base64 can be used without problems.

The only situation on which qmail-ldaps "just-send-8" may be a "problem"
is a non 8BITMIME MTA which does a check on the given content and issues
an error if 8Bit content is found. But this should generate a bounce
with qmail-ldap and mail won't get lost.

I would appreciate your point of view on this topic.

Thanks
Phil.



[prev in list] [next in list] [prev in thread] [next in thread]