Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#2083 text attachments and rfc2822 line length limits

closed-fixed
nobody
Compose (426)
5
2009-04-03
2006-04-20
Tomas Kuliavas
No

text attachments can contain more than 998 characters
in one line.

SquirrelMail attaches text attachments as is. It can
cause attachment corruption or violate rfc2822 line
length limits.

SquirrelMail 1.4.6 and 1.5.1.

I think attachments should be always encoded.

Discussion

1 2 > >> (Page 1 of 2)
  • Tomas Kuliavas
    Tomas Kuliavas
    2006-04-21

    • summary: test attachments and rfc2822 line length limits --> text attachments and rfc2822 line length limits
     
  • Logged In: YES
    user_id=285765

    I'm not in favour of encoding things that need not be
    encoded. In that case I'd rather check text attachments for
    long lines, and IFF those exist, encode it. There's just a
    minority of text attachments that have exceptionally long lines.

     
  • Tomas Kuliavas
    Tomas Kuliavas
    2006-08-18

    Logged In: YES
    user_id=225877

    Closed dublicate bug report
    [ 1542493 ] Broken text attachments longer than 998 bytes

     
  • Logged In: NO

    Hello, nobody working on this?
    It is a major problem for EDI / EDIFACT messages.

     
  • Logged In: YES
    user_id=285765

    We are all volunteers. If you really want this fixed, you
    can wait until someone does it, or fix it yourself by
    providing a useful patch. Or pay someone to do it, if you
    think it's important.

    We try to fix the bugs reported to us on a best effort base,
    and we've fixed many of the bugs already reported, but
    please consider that we're not fully paid staff that works
    on problems that you might consider important.

     
  • Logged In: NO

    Hi kink,

    I'm not sure I have the competence for doing this.
    I successfully patched/hacked some unmantained plugins
    working now with 1.52 tree.
    I guess that if you point me in the right direction (the
    original fork) I could just try a patch (simply measuring
    the length of the string >= 998).

    But I don't know Squirrelmail in depth...

     
  • Logged In: NO

    Following this old post I think the cuplrit is
    in /class/Delivery.class.php

    http://www.mail-archive.com/squirrelmail-
    users@lists.sourceforge.net/msg22490.html

    >> Thanks for your answer
    >> What should I change in this file ?
    >> If I want to turn on base64 transfer encoding do I need
    to make a
    > "hack"
    >> ?
    >> Everyone have to do this change in Deliver.class.php ?
    >> I saw some headers in the SM mailing lists and some
    users use this
    >> base64 tranfer encoding
    >> Doesn't do this SM automatically ?
    >> Thanks in advance
    >>
    >> Pet

     
  • Logged In: YES
    user_id=244001
    Originator: NO

    I've seen this bug preventing users from sending the following types of attachments:
    * RTF documents (they are plaintext and often contain all content on one line)
    * Tomcat server log files (the java exceptions that land in the logs can generate extremely long lines when class hierarchy is complex)
    * XML files
    * other types of machine-generated text files (mostly logs)

     
  • Kelly Fallon
    Kelly Fallon
    2008-11-05

    I submitted a patch for this: https://sourceforge.net/tracker/index.php?func=detail&aid=2226470&group_id=311&atid=300311

    I found this to be an issue when users were forwarding email with text/html type attachments that did not contain line breaks. SquirrelMail was creating 8bit encoded attachments with line lengths in the thousands of characters (instead of complying with the rfc specified line length).

    In my instance, when these these mails are submitted to cyrus imap via postfix, cyrus will reject the mail with 554 5.6.0 Message contains NUL characters (in reply to end of DATA command)). In fact what is going on is that cyrus is having trouble with the overly large line length.

     
  • This has been fixed in 1.4.18SVN and 1.5.2SVN. Please update and feel free to report if you still have problems. Thanks.

     
1 2 > >> (Page 1 of 2)