%TCPIP-I-SMTP_LINEWRAP, line contains more then 1000 bytes, splitting into multiple lines

[Hector Torres_1]

My server is version 8.3 of OpenVMS and gave me the message "%TCPIP-I-SMTP_LINEWRAP, line contains more then 1000 bytes, splitting into multiple lines"


In the thread Id = 1140365 mentions the solution for OpenVMS version 8.2-1

There is some fix for the final solution?

thanks and greetings ...
h_torres

[Hoff]

There appears to be some misunderstanding with what was posted over in:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1140365

The solution is, well, "don't do that".

You're trying to use SMTP past one of its inherent and defined limits. You're specifically past what the RFC indicates is supported here.

Even assuming that HP did implement a change and allowed record lengths past what the RFC specifies as a limit, it would be well within the provenance of a receiving mail server to mung the file. Or to punt it.

If you want to send files or messages with these long lines, then you can MIME-encode the message. (This was the approach described in threadId=1140365.)

Or you can use something vastly better suited for sending files around, such as sftp.

[Hector Torres_1]

Hoff Thanks for the reply ...

So as such SMTP continues with this structure, there is a patch to allow use more of the bytes currently permitted?

greetings ...
h_torres

[Volker Halle]

h_torres,

in case of IT communications, there have to be standards to describe the limits and implementations for the protocols. In this case, these are RFCs describing the various protocols.

What good would it do HP to create a 'patch', which would violate or exceed the limits specified in the appropriate standard ? It would only cause problems on the receiving end on the SMTP server. Or do you expect all SMTP server software vendors to also increase their line limit ?

If you need to send files with a line length > 1000 bytes, consider to use the workaround given in the referenced thread, i.e. use MIME encoding.

Volker.

[Hector Torres_1]

Aware, thank you very much for your attention ...

greetings ...
h_torres

[Hoff]

This behavior is not a bug.

This is a documented limit of the SMTP protocol itself.

What's broken here is what is being requested of this SMTP server. Or the expectations that the SMTP server can deal with an arbitrary-length record within the protocol.

The error here is the input with the long line.

This particular SMTP server is being polite and issuing a diagnostic message, and converting a mail message that is not compliant with the SMTP protocol into a format that will work more reliably.

It is unlikely that HP would prioritize an extension to the protocol particularly as a bug or even as a high-priority work item. This given the availability of MIME and MIME encoding (which lets you send longer-lined messages and longer-lined files via SMTP), and given that other SMTP servers are fully within their purview to reject or wrap a long-lined message as a protocol error.

Again, this is a documented limit of an Internet protocol.

Not a bug.