Well, as I say in JAMES-648, Don't like the idea of reject... And I
understand you but...
I am going to tell a history to you.
In 2003 in my ex-work requested to me mount an IMAP server (for the
people -VIP- who traveled), I wanted to use James (it seem to me more secure
than sendmail and more flexible than postfix) but finally I had to use
Cyrus-Imapd, all we know the reason.
A few months ago in the company where work since 2004 they ordered to me to
mount an Anti-Spam system, I preferred James of course.
Thursday 28/Sep the relay of the IIS that we were using was broken (in
office), was the perfect opportunity to put James but... I have bad luck,
because it seems that I am fighting against a wall, first Oracle (and his
brackets <>), next with HP and his missing encoding-headers, and more 3rd
parties that send strange mails. Peculiarly, in the 2-3 years that I take
using those things, the smtp of the IIS has not given problems (it swallows
everything), now with James yes I have a few problems.
Today (Food's time) I have returned to install the IIS (sadly).
I see non-tolerant James to strange mails that receive, compared with
Sendmail, Postfix, QMail, IIS,... perhaps James is wonderful to send, but
not to receive. ("be conservative in what you send, be liberal in what you
receive").
Obvious things:
- nobody is perfect.
- the lap belts would not have to exist; people would have to drive the car
well.
- the Spam would not have to exist, but we wrote systems anti-Spam instead
of shouting: "you do not send Spam, reads the RFC!!".
- the mail servers are for communicating.
- reject mails goes against my religion. (As programmer I like the well done
things -and RFCs-, but like sysadm my mission is that the things work,
beyond if he is good or bad -while he is safe-)
In my mind We would have to do all the possible to send well mails, but
still more, to do the impossible thing to read/parse the received mails. In
parallel with this imperfect world, warn to sysadm so that he can speak with
the person that can correct the problem, without losing mail while the
problem is corrected.
This is not a RFC violation. We called he: accomplish a mission.
Communication.
--- Guillermo
----- Original Message -----
From: "Stefano Bagnara" <[EMAIL PROTECTED]>
To: "James Developers List" <[email protected]>
Sent: Tuesday, October 03, 2006 9:28 PM
Subject: Re: [jira] Commented: (JAMES-648) Corrupted MIME message with 8bit
in body
Guillermo Grandes (JIRA) wrote:
[
http://issues.apache.org/jira/browse/JAMES-648?page=comments#action_12439630 ]
Guillermo Grandes commented on JAMES-648:
-----------------------------------------
Reject... (I change corrupt but readable, by mail to trash), No, I don't
like the idea,...
Well, rejecting it make the sender aware of the problem.
Otherwise you receive it corrupted: either way the message is invalid so
it id not a big problem if it is corrupted even more.
But seem that in this case the one that violates more the RFC is
JavaMail, that places "quoted-printable" instead of "7bit" in a message
without Content-Transfer-Encoding when modify any header of msg.
Well, I don't like JavaMail, and I lost a lot of days try to workaround
its MANY bugs, but I think this time it is not javamail that is doing it
wrong.
It is clearly stated everywhere that you cannot have 8bit chars in the
text of a message unless you use Content-Transfer-Encoding: 8bit. If no
content-transfer-encoding is there there is no rule about what to do.
Javamail adds quoted-printable simply because it find the 8bit char: try
removing the 8bit char and I bet that Javamail won't add the
Content-Transfer-Encoding anymore.
So the source message is wrong: if you add Content-Transfer-Encoding: 7bit
you will change the message and corrupt it more anyway... There is no (I
can't see it) clean solution/workaround for this: you can fix some mail,
but mangle much more the others if you add workarounds.
Stefano
Corrupted MIME message with 8bit in body
----------------------------------------
Key: JAMES-648
URL: http://issues.apache.org/jira/browse/JAMES-648
Project: James
Issue Type: Bug
Affects Versions: Trunk
Environment: James 3.0
Reporter: Guillermo Grandes
Assigned To: Norman Maurer
Attachments:
4D61696C313135393436303732323938332D323834.Repository.FileStreamStore,
james-proccesors.xml, traces.txt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
