At 5:28 AM +1100 2/10/02, Andrew Thompson  imposed structure on a 
stream of electrons, yielding:
>Well, whoever is right, it certainly appears as if BPC is
>implementing a rule. And it's sure easier for me to comply, rather
>than fight Big Pond.

Sad but probably true.

Some of us actually have Big Pond (and all the rest of Telstra's 
operations) blocked at the router level because of their repeated 
multifaceted displays of dangerous incompetence, but I guess that 
would be impractical for someone in .au...

>The mystery is how come _only_ HTML messages (not text)

Your HTML mail and text mail are (probably) coming from different 
programs that have different understandings of mail.

The HTML is probably generated by some program that is not breaking 
lines regularly or is using a linebreak that the bad MTA at Big Pond 
doesn't recognize as a linebreak. For example, both Classic MacOS and 
Windows use a bare CR for line breaking, and many programs on both 
platforms only actually insert explicit breaks at paragraph ends to 
make 'soft wrapping' of lines to fit variable windows simpler. An MTA 
trying to enforce a body line length is very likely to be looking for 
at least a LF at the end of a line, and probably a CRLF pair, so even 
if that HTML mail has lots of lines with hard Mac or Windows breaks, 
it could be seen by the cranky server as one long line. In addition, 
the concept of 'HTML mail' pretty much relies on extensions to the 
classical mail standards (notably MIME) that rely on violating some 
of the older strictures on mail format, so it is very likely that 
anything generating HTML mail will ignore some of the classical rules.

The text mail is probably originating with or passing through some 
program (like a mail client) which thinks of all mail as plain text 
and knows that plain text mail should contain mail-safe characters in 
fairly short lines terminated by CRLF pairs.

>from SIMS

SIMS will NEVER modify message data. This sounds like a good thing 
and in principle it is. In practice it USUALLY is. Unfortunately it 
sometimes means that SIMS will not handle a problem that other mail 
servers might avoid. Some mail servers will automatically re-encode 
for transit any message that arrives with a MIME Content-Type or 
encoding that isn't classically 'mail safe' (i.e. using 7-bit 
characters  and broken into nice short lines by CRLF pairs) before 
passing the message along. This is a perilous strategy for a mail 
server, since it can result in creating a message that the recipient 
cannot decode.

In the end, the problem is a trinity:

1. The mail itself violates a classical rule on mail format.
2. The Big Pond mail server is enforcing a classical rule on mail 
format that is generally considered outdated and is inconsistent with 
some modern popular mail formats.
3. SIMS is accepting the "broken" mail and not "fixing" it before 
sending it along. This is widely seen as correct MTA behavior because 
of the messes that "fixing" mail formatting can cause, however there 
are many other MTA's which will attempt such a fix and in most cases 
that fix is never noticed by anyone except in the fact that "it just 
works."

I don't think the right fix for this situation is for Stalker to 
change SIMS, since a transparent server is better than one which can 
convert mail from something a recipient can read to something they 
can't read. You've made it pretty clear (and I believe you, having 
dealt with various slimy pieces of Telstra) that getting Big Pond to 
use a mail server that fits the 1990's is not a feasible project. The 
only other option I see is to tell users that if they get this sort 
of bounce they should find whatever settings exist in the programs 
they use to compose mail to make sure that everything they send is 
linewrapped properly and/or MIME/base64 encoded.


-- 
Bill Cole
[EMAIL PROTECTED]


#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

Reply via email to