--===============1884608304==
Content-Type: multipart/signed;
  boundary="nextPart6928759.qqnf9sBFuW";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart6928759.qqnf9sBFuW
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hi :

I had an automated vcs commit email today that never came through.  When=20
another developer told me about it, and I looked into it I found it was=20
rejected : 5.7.1 disallowed character

I understand the postfix configuration in main.cf

message_reject_characters =3D \0

I read through the comments, and also kolab/issue3594.  It was suggested=20
originally to use message_strip_characters =3D \0, but was decided on rejec=
t=20
instead.

I am wondering if there is anything wrong with using strip, instead of reje=
ct=20
here?  If the null byte is removed, there should be no problems for cyrus=20
with it right?

I couldn't find any argument for reject over strip, other than it would not=
=20
changing the message content.  But what content would actually require thos=
e=20
null bytes?  Does anyone know of any reason to not just strip those out, an=
d=20
let the messages through?


Andy

--nextPart6928759.qqnf9sBFuW
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBNJSl2YcSSDa/HK6ARAgJpAKCMezWL1Yfmmc7hh4SETWKJWg8FtACgp0TJ
ISrqZ/syTsrfTzbRM0oQmYI=
=PE0n
-----END PGP SIGNATURE-----

--nextPart6928759.qqnf9sBFuW--


--===============1884608304==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kolab-users mailing list
Kolab-users@kolab.org
https://kolab.org/mailman/listinfo/kolab-users

--===============1884608304==--