On Thu, Aug 14, 2014 at 6:42 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
On Wed, Aug 13, 2014 at 6:34 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com>
wrote:
Let me try one more time, since something isn't making it through.
I have three messages. One message has an entirely 7bit header with
2047
encoded subject. Another message is a 6532 message, with the
subject in
utf8. A third message is has a cp-1250 8bit subject. There are two
8bit
bytes in the subject in both of the last two messages, and in the
cp1250
case, those two bytes happen to also be a valid utf8 character.
We want to be able to parse all three of those and do so correctly.
We
know the third type is technically invalid, but we see millions of
such
messages every day, dropping all of those would be a dis-service to
our
users. We currently see way more of such messages than we do of 6532
messages... though in practice, the most common charset now is
utf-8, so
I
guess those are now the same as 6532 messages that have leaked.
I thought I understood the problem you were attempting to solve, but
now
I'm
totally confused, because this seems to hqve nothing to do with
additional
labeling of legitimate EAI messages at all.
My point is that without a label, I can't tell the difference between the
6532 messages and the illegitimate messages, given just the message.
Yes, that's exactly what I thought. But given that, surely it makes more
sense
to label the illegimate messages as such, especially since you're going to
want
to set the EAI message bit for some of them, making it essentally an
orthogonal
setting?
Did you even bother to read the rest of my response?
Yes, but I didn't understand it until this response. It is an interesting
alternative. You still seem to be assuming an external eai bit, but even
without that, yes, theoretically we could mark any non legitimate message
at smtp-in time. It would be harder to do at imap APPEND time, though,
since I believe clients assume the messages as uploaded are stored as is..
I'd have to test to see if that was a failure. Potentially, I would have
to be careful with any source of messages to make sure .. and that means we
may need to upgrade our other api's and migration tools to have a bit for
eai.
Brandon
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822