MailMessage subject line non-compliant with RFC 2047

[asphalttech]

I have been trying to workaround a non-compliancy issue within version 4.0 of the .NET framework. According to RFC 2047, in the subject line an encoded word can not be longer than 75 characters. If it is, it must be broken up into multiple encoded words separated by CRLF SPACE.

If you use the MailMessage class and try to assign a string with CR or LF, it throws an exception. Internally, it is calling MailBnfHelper.H asCROrLF(value) and if true it throws the exception.

I was hoping to make use of reflection, but can't seem to make it work for me.

Inside of the MailMessage class, the subject line is a private member of type (class) Message. So I would first need to find a way to access this private class. Inside of the Message class, I would need to access the private string "subject". This is the value I would directly need to set so as to avoid the internal Set property.

So far I have had no luck trying to achieve this.

Does anyone have any pointers on how to properly reflect on a setup such as this?

Is this even possible?

Thanks for any help in advance!

[Frinavale]

Sorry but I don't understand what you are trying to do?
A subject line is just a subject line.
What's wrong with adding a space in between words within the string that contains the subject?

-Frinny

[asphalttech]

A subject line is not just a simple string. Within the class MailMessage, the subject line is actually defined as follows:

private Message message;

When you set MailMessage.Sub ject, it actually does:

public string Subject
    {
      get
      {
        if (this.message.Subject == null)
        {
          return string.Empty;
        }
        return this.message.Subject;
      }
      set
      {
        this.message.Subject = value;
      }
    }

Within the Message class, when it sets the Subject field, it is going through the following:

   internal string Subject
    {
      get
      {
        return this.subject;
      }
      set
      {
        if ((value != null) && MailBnfHelper.HasCROrLF(value))
        {
          throw new ArgumentException(SR.GetString("MailSubjectInvalidFormat"));
        }
        this.subject = value;
        if (((this.subject != null) && (this.subjectEncoding == null)) && !MimeBasePart.IsAscii(this.subject, false))
        {
          this.subjectEncoding = Encoding.GetEncoding("utf-8");
        }
      }
    }

Within the Message class, the subject line is finally defined as:

private string subject;

I am looking for a way to directly modify this private string in the Message class (which I think I should be able to do through reflection).

Based on the above, an exception will be thrown if the string contains a carriage return or line feed. However, this is in direct violation of RFC 2047 which states:

An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.

While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
'encoded-word's is limited to 76 characters.

The length restrictions are included both to ease interoperabilit y
through internetwork mail gateways, and to impose a limit on the
amount of lookahead a header parser must employ (while looking for a
final ?= delimiter) before it can decide whether a token is an
"encoded-word" or something else.

So I am looking to get around this restriction in the .NET 4.0 framework. I have not had to use reflection before, but I believe I should be able to get access to the private string in the message class and set the value directly, bypassing the CRLF check but I have been unsuccessful in my attempts.

Does anyone know how to properly reflect on this field and set its value, or know of another way to be compliant?

Thank you for any help provided!

[Frinavale]

You cannot access the private members of a class using Reflection.

You can access them when you are providing a copy operator or casting operators....bu t that's not what you are doing.

I still cannot fathom why you would want to force invalid data to be used as the subject line.

-Frinny

[asphalttech]

I appreciate your responses. So it sounds like reflection is a no go.

I want to do this because this is how long encoded words are supposed to be handled.

http://www.ietf.org/rfc/rfc2047.txt

Page 3, "2. Syntax of encoded-words"

Unless this is outdated at this point? Maybe I don't need to be worried about it? I'm just trying to follow the spec.

I've tried not breaking it up into multiple encoded words with more characters than 75 and I didn't see an issue, but I don't have a way to effectively test all the email gateways that our customers may be using.