@jhillyerd I think that if a user wants to include a delimiter with a quoted-string, it must be done using RFC2047 encoding. Such that a filename like:

name="Index\";a.doc"

is rendered as:

name="=?UTF-8?B?SW5kZXhcIjthLmRvYw==?="

So here is a nice quote from that SO thread:

Figuring out what exactly the RFC stipulates is not going to be actually useful. The de facto standard you need to adhere to for interoperability is set by poorly implemented mail clients and browsers. If that's your goal, I would not expect anything like escaping to work reliably, regardless of whether the RFC is on your side.

So I looked up mozilla's libraries and found some stuff of interest: https://github.com/mozilla-comm/jsmime/blob/master/headerparser.js#L29 Quoted-strings (if opt.qstring is true): A string which is surrounded by double quotes. Escapes in the string are omitted when returning.

Another note about this behavior: [Whitespace] need not be between a qstring and an atom (a"b" produces two tokens, a and b). This is an error case, though.

However, in the implementation I see a tell: This is at the head of the character iteration loop which is designed to detect quoted-strings and domain-literals.

    // If we see a \, no matter what context we are in, ignore the next
    // character.
    if (ch == '\\') {
      i++;
      continue;
    }

So it looks like the accepted best practice here is simply to omit any escaped characters, whether or not it's within a quoted-string.

I'm still looking for how they handle single versus double quotes inside each other, like the proposed test-case: "a;'b;c;d"

Ah, okay, so only double-quotes are respected as quoted-string delimiters, and single-quotes are treated as just another character.

So the want here should be:

		{
			input: "a;'b;c;d",
			want:  []string{"a", "'b", "c", "d"},
		},

I can picture two possible alternatives; if we hit the end of the string and find it has an unterminated quote:

1. Start over and split the entire string without respecting separator quoting at all -- aka how enmime worked previously, since it didn't have a notion of quoting.
2. Reset to the last opening quote and pretend it didn't exist; so earlier quoted runs would be respected.

I'd lean towards the first option, given we don't know which quote(s) may be missing, the second isn't going to be any safer than what the code does now.

Yeah, it's definitely more aggressive than I'd like. Haven't looked into tuning it, but given enmime is dealing with potentially hostile external email for many folks, probably want static checks.

👀 today

@requaos and @dcormier -- if either of you have time to review this PR, feedback appreciated. Thanks!

It looks like others are also unclear about contents and escaping of quoted strings: https://stackoverflow.com/questions/59816619/do-quoted-mime-media-type-parameters-allow-escaped-quotes

Given that Go let's us escape things with its mime library, I will try to support it as well.

https://play.golang.org/p/r_8sUV16lax

I feel using the term envelope here could be confusing since the parsing portion of the library has an Envelope struct. It appears the RFCs use the term "return path" -- but that also seems a bit dated. How about ReturnAddress?

@jhillyerd Yes, I need a different address in the envelope. I don't know if the function name 'SendWithEnvelopFrom' is the best, maybe you have a better idea.

Thanks for sending this PR, can you elaborate it's purpose? Do you need the from value send to the SMTP server to be different from that of the email headers?

If you are just looking to have multiple from addresses:

Each manipulation method returns a copy of the receiver struct. It can be considered immutable if the caller does not modify the string and byte slices passed in. Immutability allows the headers or entire message to be reused across multiple threads.

This means you can setup an email and send it with different from already:

msg := Builder()
// configure message

msg.From("Bob", "[email protected]").Send(...)
msg.From("Fred", "[email protected]").Send(...)

Fixes #174

• [x] Build and test
• [x] Static analysis
• [x] Test coverage
• [x] Remove travis
• [x] Fix lint errors

Closes #173

Travis CI has been slow and buggy for months, and it appears they would like their open source users to go elsewhere: https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works

GitHub Actions is likely to be the best replacement.