1. 03 Sep, 2014 1 commit
    • Alex Vandiver's avatar
      Standardize on the stricter Encode::encode("UTF-8", ...) everywhere · 1d18663b
      Alex Vandiver authored
      This is not only for code consistency, but also for consistency of
      output.  Encode::encode_utf8(...) is equivalent to
      Encode::encode("utf8",...) which is the non-"strict" form of UTF-8.
      Strict UTF-8 encoding differs in that (from `perldoc Encode`):
      
          ...its range is much narrower (0 ..  0x10_FFFF to cover only 21 bits
          instead of 32 or 64 bits) and some sequences are not allowed, like
          those used in surrogate pairs, the 31 non-character code points
          0xFDD0 .. 0xFDEF, the last two code points in any plane (0xXX_FFFE
          and 0xXX_FFFF), all non-shortest encodings, etc.
      
      RT deals with interchange with databases, email, and other systems.  In
      dealing with encodings, it should ensure that it does not produce byte
      sequences that are invalid according to official Unicode standards.
      1d18663b
  2. 09 May, 2013 1 commit
  3. 08 May, 2013 3 commits
  4. 17 Dec, 2012 2 commits
  5. 26 Jul, 2012 1 commit
    • Jim Brandt's avatar
      Improve logging for failed sender parsing in email · 1ba0f1a9
      Jim Brandt authored
      Starting with version 1.893, Email::Address returns undef
      if passed non-ASCII email addresses to parse.
      
      Track such email parsing failures in ParseSenderAddressFromHead and
      pass them back as an optional third parameter. This allows the
      caller to report the error if desired. Failure to parse one message
      will generate an error, but the function can still find and return
      a valid address from another header. This function is
      called from several places and returning the error rather than reporting
      avoids multiple warnings from parsing the same emails.
      
      ParseSenderAddressFromHead still reports a failure to find a sender
      in any header, since that is an error. That message will be reported
      multiple times, one for each call to the function.
      
      Update MailFrom.pm's GetCurrentUser to report the parse failures
      as a warning. These parse failures are reported even if a sender
      was found in another header. Also update the existing error in
      GetCurrentUser to indicate that a parsing failure can also
      prevent finding a valid sender.
      1ba0f1a9