Subject: line length limit in RFC 821 and the draft-ietf-drums-smtpupd-10. txt

From: "Garmann, Bernhard" <[email-masked]>
Date: Mon, 21 Jun 1999 12:23:55 +0200

Greetings,

sorry to bother you with these humble questions, but there seems to be no
better authority.

I am working on a syntax specification, to map the fields of a trouble
report onto a
Formalized ASCII message format, send it by SMTP between telecommunication
providers and potentially customers - sort of an EDI type application.
(It's a group effort and I could not convince them to use XML).

Now the problem:
Reading RFC 921 and the following draft revision:
draft-ietf-drums-smtpupd-10.txt,
it states, that the line limit is kept at 1000 chars per line, and the
reminder , that this
can be overridden through a service extension.

To my knowledge such a service extension does not exist.

What happens, if the limit is there ?
How is it made known to local upper layers, in order for these to ensure
that the limit is never violated ?
Or in other terms, what is an SMTP entity supposed to do with a locally
received (from a user's MUA)
input line, that exceeds the limit, and may well be longer than 1000 chars ?

Shouldn't the local MUAs (or other entities), that are the ultimate source
and sink of an
email message (and it's format) be designed not to allow longer lines ?

Hope you can shed some light on this issue.

MfG

Bernhard Garmann
Diplom Informatiker (FH)
----------------------------------------------------------------------------
----------------------------------
Address:   
----------------------------------------------------------------------------
----------------------------------
Bernhard Garmann
VIAG Interkom GmbH & Co
Geschäftsstelle
Riesstraße 25
80992 München
Germany
FON:		+49 (0)89 1480 - 3224
Mob:		+49 (0) 179 6960639
FAX:		+49 (0)89 1480 - 3873
email: [email-masked]
www.viaginterkom.de
----------------------------------------------------------------------------
----------------------------------
"Diese Anwendung wird aufgrund eines ungültigen Vorgangs beendet."
"Wenden Sie sich an den Hersteller, falls das Problem weiterhin besteht."
"Too much Bill, too many bugs - you get what you pay for."

---

From: Matti Aarnio <[email-masked]>
Date: Mon, 21 Jun 1999 18:38:56 +0300 (EET DST)

> (It's a group effort and I could not convince them to use XML).

	The best interoperability you will get by following MIME rules,
	don't try to make (at email/smtp) a single monsterously long line
	which then has occasional problems going thru.

	Easiest way to handle this is to use QUOTED-PRINTABLE format for
	the message content.  It has nice line folding/unfolding facility.

	If your coding approach is sufficiently modular, you can do the
	message writing thru e.g. some abstraction layer which does the
	Q-P encoding while writing the message body.

	At work I have a customer who is exchangeing EDI messages, and those
	are essentially TEXT/PLAIN messages containing *one* line; often
	that is hellishly long one.

	Our customer wanted not to write Q-P decoder at their side, so our
	MTA had to decode the incoming Q-P into their message store, and then
	we noticed that the POP3 server we had did split lines exceeding some
	internal buffer size ... that POP3 server did need a patch.

> email: [email-masked]

/Matti Aarnio <[email-masked]>