Tony Hansen wrote:
>> That has it's problems, too. I had an issue with a legit corporate
>> sender that added a malformed header line in the middle, before the
>> From: and To: fields. Result was that people's filters didn't work.
> Garbage input leads to "interesting" results, no matter what choice
> was taken.
Sure, just sayin' that both approaches resulted in calls to customer
service. In my experience, though, most of the time when the receiver
inserted the blank line, it was inserted in the correct place.
We provide both options, by the default is to insert, and we've found it
generates fewer calls.
There are other malformations that aren't so clear cut, though. The example
that immediately comes to mind is:
Content-type: multipart/mixed; boundary=whatever
Content-transfer-encoding: base64
As of today, when we see exampples of this it usually means the multipart isn't
encoded and the line needs to be ignored to properly process the messsage. But
some years back the odds were it meant the part really was encoded, never mind
the nested encoding prohibition. The best handling choice has changed over
time.
But if EAI is successful the nested encoding restirction is going to go away.
that may tilt this back the other direction, for subtypes of message at least.
We actually get reports of issues with this malformation a lot more often than
we see problems with header termination.
Ned