Given that the RFCs are vague, and that EVERY server we've tested (except Courier) supports insanely long line lengths (we tested with 1,000,000 byte-long lines), it looks incredibly bad for us and Courier that it doesn't work on our system. There's a lot of RFC-enforcing that I'm willing to argue for, but this one is just too far out there.
Given this, what can we do?
what's your intention with this?
apparently you haven't testet EVERY AVAILABLE mta, so you might run into
problems later.
Obviously I can only test with the ones I know about. And I agree, honoring the RFCs is more important than breaking them blindly. But the RFCs in this case explicitly say: "Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake." There's nothing to argue here. Every server we've tested -- except Courier -- implements this suggestion from the RFC.
imagine courier accepting the mail from your customers. now what to do with
this very long lines? well, for security, we'll just send them out. we could
break the whole mail not only if it contains attachments, but also
gpg/pgp-mails. just leave it with long lines. but what if the
next-hop-server doesn't like our mails? right, they bounce. and with that,
we give it back to your customers.
Are there any issues with the MTA, upon receiving 1,000+ byte lines, re-encoding the body as a mime type (pgp sigs included) in an RFC-compliant form? Or how about using the BDATA extension to SMTP?
seems to me, that you just want that problem off your shoulders, and that
all mtas you've tested don't want to get involved with mailserver-admins
like you complaining about software that was coded as the rfc says.
You're right. I don't want there to be any problems.
i suggest then, you use whatever mta supports those long lines and later
describe them that the recipients of their mails can't get them because you
use a non-rfc-compliant mta.
Is this what every Sendmail admin does? What every Postfix admin does? What every Groupwise admin does? What every Exchange admin does? What every Merak admin does?
No. They blame Courier.
We're at the point of a bunch of admins sitting across from each other, point fingers, and sticking tongues out, each side claiming to be Right. I don't care about "being" Right. I care about all of our various systems communication correctly, following the RFCs, and being tolerant of the occasional rfc-ignorant coder in as much as it doesn't break an rfc. ("Be generous in what you receive, strict in what you send.")
I like Courier very, very much. I have a lot of trust in Sam to balance the right thing in such a way that it's still interoperable. (And, occasionally, disagree, e.g. return-path headers or skipping over non-rfc-1035 mx records to find a suitable one.) I'm hoping in this instance that Sam will reconsider and come up with a workable solution.
best, Jeff
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
