Annoying feature of SMTP receiver which breaks POP/IMAP - VMS

This is a discussion on Annoying feature of SMTP receiver which breaks POP/IMAP - VMS ; The SMTP receiver (or symbiont) has a feature which will insert a line break whenever a line exceeds 255 characters. So, if a header has a line which exceeds 255 characters, The first 255 are printed, then the remainder are ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Annoying feature of SMTP receiver which breaks POP/IMAP

  1. Annoying feature of SMTP receiver which breaks POP/IMAP

    The SMTP receiver (or symbiont) has a feature which will insert a line
    break whenever a line exceeds 255 characters.

    So, if a header has a line which exceeds 255 characters, The first 255
    are printed, then the remainder are printed starting at column 1 on the
    next line. (and I assume that if that line exceeds 255, it too will be
    folded into more lines.)

    The end result is that you have an illformed header. And unfortunatly,
    both POP and IMAP parse the RFC822 headers and when they encounter an
    illformed one, they treat it as text and synthetise a vanilla header.

    For a text message, this isn't the end of the world. But when the
    message contains attachements, it means that a smart client on some
    other platform will see the faked vanilla header instead of the real one
    below and thus will not have a clue that this is a multipart message and
    no clue what is the boundary between parts is.

    The only way to fix this is to go into VMS, fire up MAIL or DECW$MAIL,
    get the actual file name of the message, edit that file to correct the
    header and then get the client to redoaload the message via IMAP or POP.
    (via POP, it would be harder since the message is already marked as READ.)

    Today, I had 5 important messages that I had to manually edit.


    I realise that because of 1970s limitation of DECnet, messages cannot
    have lines exceeding 255 characters.

    I would therefore suggest that the receiver be modified to either:

    Parse the header with logic that will insert a newline AND a space when
    it must break lines, and perhaps break them smartly after a white space
    or a coma instead of blindly breaking them at position 255. This would
    result in a properly formatted header.

    Then, once it has encountered a blank line, it can proceed with the
    normal line folding when it finds long lines. I would suggest that
    there, it should fold only at the last encountered whitespace before
    reaching 255.

    Alternatively, a setting in SMTP.CONF to not fold lines at all which
    could be used for shops that no longer transfer mail via the 1970s
    DECnet mail interface.

  2. Re: Annoying feature of SMTP receiver which breaks POP/IMAP

    On 2008-09-17 04:58, "JF Mezei" wrote:

    > The SMTP receiver (or symbiont) has a feature which will insert a line
    > break whenever a line exceeds 255 characters.


    Platform? OS version? IP stack vendor? Version? ;-)

    > So, if a header has a line which exceeds 255 characters, The first 255
    > are printed, then the remainder are printed starting at column 1 on the
    > next line. (and I assume that if that line exceeds 255, it too will be
    > folded into more lines.)


    Quoting from RfC 2822, Section 2.2.3 ("Long Header Fields"):

    | [...] a CRLF may be inserted before any WSP.

    I.e., long lines _must_ not be broken at arbitrary positions. And
    obviously that "white space" will be moved to the continuation line.

    > [...]
    >
    > I realise that because of 1970s limitation of DECnet, messages cannot
    > have lines exceeding 255 characters.


    Quoting from RfC 2822, Section 2.1.1 ("Line Length Limits"):

    | [...] Each line of characters MUST be no more than 998 characters,
    | and SHOULD be no more than 78 characters, excluding the CRLF.

    > I would therefore suggest that the receiver be modified to either:
    >
    > Parse the header with logic that will insert a newline AND a space when
    > it must break lines, and perhaps break them smartly after a white space

    ^^^^^
    > or a coma instead of blindly breaking them at position 255. This would
    > result in a properly formatted header.


    s/after/before

    > [...]
    >
    > Alternatively, a setting in SMTP.CONF to not fold lines at all which

    ^^^^^^^^^^^^^^^^^^^^^
    > could be used for shops that no longer transfer mail via the 1970s
    > DECnet mail interface.


    It isn't just DECnet ...

    Michael

    --
    Real names enhance the probability of getting real answers.
    My e-mail account at DECUS Munich is no longer valid.

+ Reply to Thread