threads / patch / 12861

patch, 2 partssend-email: rfc2047-quote subject lines with non-ascii characters

Subject: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

## tl;dr

11 messages between Mar 25, 2008 and Mar 27, 2008. Diffs are folded; open one to read it.

replies: 10people: 3as markdown or json

Jeff King· Mar 25, 2008, 23:03 UTC · lore

We always use 'utf-8' as the encoding, since we currently have no way of getting the information from the user.

This also refactors the quoting of recipient names, since both processes can share the rfc2047 quoting code.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-send-email.perl   |   18 +++++++++++++++---
 t/t9001-send-email.sh |   15 +++++++++++++++
 2 files changed, 30 insertions(+), 3 deletions(-)
Show changes to 2 files +30 −3

git-send-email.perl, t/t9001-send-email.sh

diff --git a/git-send-email.perl b/git-send-email.perl
index 7c4f06c..075cd0b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -501,7 +501,12 @@ if ($compose) {
 	open(C,">",$compose_filename)
 		or die "Failed to open for writing $compose_filename: $!";
 	print C "From $sender # This line is ignored.\n";
-	printf C "Subject: %s\n\n", $initial_subject;
+	print C "Subject: ",
+		($initial_subject =~ /[^[:ascii:]]/ ?
+		quote_rfc2047($initial_subject) :
+		$initial_subject),
+		"\n";
+	print C "\n";
 	printf C <<EOT;
 GIT: Please enter your email below.
 GIT: Lines beginning in "GIT: " will be removed.
@@ -626,6 +631,14 @@ sub unquote_rfc2047 {
 	return wantarray ? ($_, $encoding) : $_;
 }
 
+sub quote_rfc2047 {
+	local $_ = shift;
+	my $encoding = shift || 'utf-8';
+	s/([^-a-zA-Z0-9!*+\/])/sprintf("=%02X", ord($1))/eg;
+	s/(.*)/=\?$encoding\?q\?$1\?=/;
+	return $_;
+}
+
 # use the simplest quoting being able to handle the recipient
 sub sanitize_address
 {
@@ -643,8 +656,7 @@ sub sanitize_address
 
 	# rfc2047 is needed if a non-ascii char is included
 	if ($recipient_name =~ /[^[:ascii:]]/) {
-		$recipient_name =~ s/([^-a-zA-Z0-9!*+\/])/sprintf("=%02X", ord($1))/eg;
-		$recipient_name =~ s/(.*)/=\?utf-8\?q\?$1\?=/;
+		$recipient_name = quote_rfc2047($recipient_name);
 	}
 
 	# double quotes are needed if specials or CTLs are included
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index e222c49..a4bcd28 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -210,4 +210,19 @@ test_expect_success '--compose respects user mime type' '
 	! grep "^Content-Type: text/plain; charset=utf-8" msgtxt1
 '
 
+test_expect_success '--compose adds MIME for utf8 subject' '
+	clean_fake_sendmail &&
+	echo y | \
+	  GIT_EDITOR=$(pwd)/fake-editor \
+	  GIT_SEND_EMAIL_NOTTY=1 \
+	  git send-email \
+	  --compose --subject utf8-sübjëct \
+	  --from="Example <nobody@example.com>" \
+	  --to=nobody@example.com \
+	  --smtp-server="$(pwd)/fake.sendmail" \
+	  $patches &&
+	grep "^fake edit" msgtxt1 &&
+	grep "^Subject: =?utf-8?q?utf8-s=C3=BCbj=C3=ABct?=" msgtxt1
+'
+
 test_done

-- 
1.5.5.rc1.123.ge5f4e6
Teemu Likonen· Mar 26, 2008, 05:59 UTC · re: Jeff King · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

Jeff King kirjoitti:
Show 5 quoted lines
> We always use 'utf-8' as the encoding, since we currently
> have no way of getting the information from the user.
>
> This also refactors the quoting of recipient names, since
> both processes can share the rfc2047 quoting code.

These patches seem to work except that the quoting of Subject field works only if user types a non-Ascii text to the "What subject should the initial email start with?" prompt. If she changes the subject in editor it won't be rfc2047-quoted.

Thank you anyway, I think we're going to right direction. I think 'git send-mail --compose' is nice way to produce introductory message to patch series. If --compose doesn't support MIME encoding reasonable way, user may have to write and send intro message with real MUA and find out the Message-Id for correct In-Reply-To field for the actual patch series.

E-mail agents KMail and Mutt have setting for preferred encodings for outgoing mail. It's a list of encodings, like "us-ascii,iso-8859-1,utf-8". The first one that fits (including From, To, Cc, Subject, the body, ...?) is used, so there is some kind of detection of content after the message has been composed.

If portable content encoding detection is difficult or considered unnecessary, then I think a documented configurable option is fine (UTF-8 by default).

Jeff King· Mar 26, 2008, 06:20 UTC · re: Teemu Likonen · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

On Wed, Mar 26, 2008 at 07:59:48AM +0200, Teemu Likonen wrote:
> These patches seem to work except that the quoting of Subject field 
> works only if user types a non-Ascii text to the "What subject should 
> the initial email start with?" prompt. If she changes the subject in 
> editor it won't be rfc2047-quoted.

Ah, yes, I hadn't considered that. We should definitely do the quoting after all of the user's input. Replace 2/2 from my series with the patch below, which handles this case correctly (and as a bonus, the user sees the unencoded subject in the editor, which is much more readable).

Show 6 quoted lines
> Thank you anyway, I think we're going to right direction. I think 'git 
> send-mail --compose' is nice way to produce introductory message to 
> patch series. If --compose doesn't support MIME encoding reasonable 
> way, user may have to write and send intro message with real MUA and 
> find out the Message-Id for correct In-Reply-To field for the actual 
> patch series.

git-format-patch recently got a --cover-letter option which does the same thing. I actually use a real MUA (mutt) instead of send-email, and this way you can avoid the message-id cutting and pasting that is required. It automatically does the right thing with encodings because I end up sending the message using my MUA.

Show 5 quoted lines
> E-mail agents KMail and Mutt have setting for preferred encodings for 
> outgoing mail. It's a list of encodings, 
> like "us-ascii,iso-8859-1,utf-8". The first one that fits (including 
> From, To, Cc, Subject, the body, ...?) is used, so there is some kind 
> of detection of content after the message has been composed.

Yes, the git-send-email code is a real mess for this sort of thing. I think it started very small and specific, and has gotten hack upon hack piled on it. It would be much nicer rewritten from scratch around one of the many abstracted perl mail objects (though that does introduce a new dependency).

> If portable content encoding detection is difficult or considered 
> unnecessary, then I think a documented configurable option is fine 
> (UTF-8 by default).
I think that is sensible. Want to try adding it on top of my patches?
Below is the revised subject-munging patch.

-- >8 -- send-email: rfc2047-quote subject lines with non-ascii characters

We always use 'utf-8' as the encoding, since we currently have no way of getting the information from the user.

This also refactors the quoting of recipient names, since both processes can share the rfc2047 quoting code.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-send-email.perl   |   20 ++++++++++++++++++--
 t/t9001-send-email.sh |   15 +++++++++++++++
 2 files changed, 33 insertions(+), 2 deletions(-)
Show changes to 2 files +33 −2

git-send-email.perl, t/t9001-send-email.sh

diff --git a/git-send-email.perl b/git-send-email.perl
index 7c4f06c..3694f81 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -536,6 +536,15 @@ EOT
 		if (!$in_body && /^MIME-Version:/i) {
 			$need_8bit_cte = 0;
 		}
+		if (!$in_body && /^Subject: ?(.*)/i) {
+			my $subject = $1;
+			$_ = "Subject: " .
+				($subject =~ /[^[:ascii:]]/ ?
+				 quote_rfc2047($subject) :
+				 $subject) .
+				"\n";
+			}
+		}
 		print C2 $_;
 	}
 	close(C);
@@ -626,6 +635,14 @@ sub unquote_rfc2047 {
 	return wantarray ? ($_, $encoding) : $_;
 }
 
+sub quote_rfc2047 {
+	local $_ = shift;
+	my $encoding = shift || 'utf-8';
+	s/([^-a-zA-Z0-9!*+\/])/sprintf("=%02X", ord($1))/eg;
+	s/(.*)/=\?$encoding\?q\?$1\?=/;
+	return $_;
+}
+
 # use the simplest quoting being able to handle the recipient
 sub sanitize_address
 {
@@ -643,8 +660,7 @@ sub sanitize_address
 
 	# rfc2047 is needed if a non-ascii char is included
 	if ($recipient_name =~ /[^[:ascii:]]/) {
-		$recipient_name =~ s/([^-a-zA-Z0-9!*+\/])/sprintf("=%02X", ord($1))/eg;
-		$recipient_name =~ s/(.*)/=\?utf-8\?q\?$1\?=/;
+		$recipient_name = quote_rfc2047($recipient_name);
 	}
 
 	# double quotes are needed if specials or CTLs are included
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index e222c49..a4bcd28 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -210,4 +210,19 @@ test_expect_success '--compose respects user mime type' '
 	! grep "^Content-Type: text/plain; charset=utf-8" msgtxt1
 '
 
+test_expect_success '--compose adds MIME for utf8 subject' '
+	clean_fake_sendmail &&
+	echo y | \
+	  GIT_EDITOR=$(pwd)/fake-editor \
+	  GIT_SEND_EMAIL_NOTTY=1 \
+	  git send-email \
+	  --compose --subject utf8-sübjëct \
+	  --from="Example <nobody@example.com>" \
+	  --to=nobody@example.com \
+	  --smtp-server="$(pwd)/fake.sendmail" \
+	  $patches &&
+	grep "^fake edit" msgtxt1 &&
+	grep "^Subject: =?utf-8?q?utf8-s=C3=BCbj=C3=ABct?=" msgtxt1
+'
+
 test_done

-- 
1.5.5.rc1.123.ge5f4e6
Teemu Likonen· Mar 26, 2008, 08:30 UTC · re: Jeff King · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

Jeff King wrote:
Show 11 quoted lines
> On Wed, Mar 26, 2008 at 07:59:48AM +0200, Teemu Likonen wrote:
> > These patches seem to work except that the quoting of Subject field
> > works only if user types a non-Ascii text to the "What subject
> > should the initial email start with?" prompt. If she changes the
> > subject in editor it won't be rfc2047-quoted.
>
> Ah, yes, I hadn't considered that. We should definitely do the quoting
> after all of the user's input. Replace 2/2 from my series with the
> patch below, which handles this case correctly (and as a bonus, the
> user sees the unencoded subject in the editor, which is much more
> readable).
It seems to work nicely after I fixed one unmatching bracket. See below.
Show 5 quoted lines
> git-format-patch recently got a --cover-letter option which does the
> same thing. I actually use a real MUA (mutt) instead of send-email,
> and this way you can avoid the message-id cutting and pasting that is
> required. It automatically does the right thing with encodings because
> I end up sending the message using my MUA.

I had missed the --cover-letter option completely. It may be useful too. I'm still trying to find the best way to send pathces. If I send intro message with real MUA I either need to wait for the message to show up on a mailing list or check my sent-mail folder to find the Message-Id. Once I know the Message-Id I can send the actual patch series with 'git send-email' as replies to the intro message. Well, this is OK.

Show 5 quoted lines
> > If portable content encoding detection is difficult or considered
> > unnecessary, then I think a documented configurable option is fine
> > (UTF-8 by default).
>
> I think that is sensible. Want to try adding it on top of my patches?

I'd like to, but I can only do sh/bash stuff and possibly some copy-and-paste programming with other scripting languages. You'd end up fixing my code anyway, sorry.

As you noticed, I accidentally sent you a couple of test emails because send-email CCed mails to patches' author (I think). Now I have set "suppresscc = all" and "suppressfrom = true" which should prevent such accidents. Shouldn't these be defaults? In my opinion it's generally the best practice to always explicitly define what parties emails are sent to.

There is unmatching bracket in your patch:
Show 16 quoted lines
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 7c4f06c..3694f81 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -536,6 +536,15 @@ EOT
>  		if (!$in_body && /^MIME-Version:/i) {
>  			$need_8bit_cte = 0;
>  		}
> +		if (!$in_body && /^Subject: ?(.*)/i) {
> +			my $subject = $1;
> +			$_ = "Subject: " .
> +				($subject =~ /[^[:ascii:]]/ ?
> +				 quote_rfc2047($subject) :
> +				 $subject) .
> +				"\n";
> +			}
                        ^-- Shouldn't we remove this one?
> +		}
Jeff King· Mar 26, 2008, 08:39 UTC · re: Teemu Likonen · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

On Wed, Mar 26, 2008 at 10:30:33AM +0200, Teemu Likonen wrote:
Show 6 quoted lines
> I had missed the --cover-letter option completely. It may be useful too.
> I'm still trying to find the best way to send pathces. If I send intro
> message with real MUA I either need to wait for the message to show up
> on a mailing list or check my sent-mail folder to find the Message-Id.
> Once I know the Message-Id I can send the actual patch series with 'git
> send-email' as replies to the intro message. Well, this is OK.

That is how I used to do it; now I use --cover-letter (which you probably missed because it is brand new in the upcoming 1.5.5).

> > I think that is sensible. Want to try adding it on top of my patches?
> I'd like to, but I can only do sh/bash stuff and possibly some
> copy-and-paste programming with other scripting languages. You'd end up
> fixing my code anyway, sorry.

OK, I will add it to the end of my long todo. Out of curiosity, do you actually want something besides utf-8, or is this just to make us feel feature complete?

Show 6 quoted lines
> As you noticed, I accidentally sent you a couple of test emails because
> send-email CCed mails to patches' author (I think). Now I have set
> "suppresscc = all" and "suppressfrom = true" which should prevent such
> accidents. Shouldn't these be defaults? In my opinion it's generally the
> best practice to always explicitly define what parties emails are sent
> to.

I think this is probably a good change. But it is a behavior change, which means it is definitely out during the -rc freeze. And it may or may not need a warning period for users.

> There is unmatching bracket in your patch:

Argh, yes. I _thought_ I ran it successfully through the test script, but obviously I failed to 'make' and just tested the previous version. It works fine with the bracket removed.

For reference, the fixed-up patch is below.

-- >8 -- send-email: rfc2047-quote subject lines with non-ascii characters

We always use 'utf-8' as the encoding, since we currently have no way of getting the information from the user.

This also refactors the quoting of recipient names, since both processes can share the rfc2047 quoting code.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-send-email.perl   |   19 +++++++++++++++++--
 t/t9001-send-email.sh |   15 +++++++++++++++
 2 files changed, 32 insertions(+), 2 deletions(-)
Show changes to 2 files +32 −2

git-send-email.perl, t/t9001-send-email.sh

diff --git a/git-send-email.perl b/git-send-email.perl
index 7c4f06c..d0f9d4a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -536,6 +536,14 @@ EOT
 		if (!$in_body && /^MIME-Version:/i) {
 			$need_8bit_cte = 0;
 		}
+		if (!$in_body && /^Subject: ?(.*)/i) {
+			my $subject = $1;
+			$_ = "Subject: " .
+				($subject =~ /[^[:ascii:]]/ ?
+				 quote_rfc2047($subject) :
+				 $subject) .
+				"\n";
+		}
 		print C2 $_;
 	}
 	close(C);
@@ -626,6 +634,14 @@ sub unquote_rfc2047 {
 	return wantarray ? ($_, $encoding) : $_;
 }
 
+sub quote_rfc2047 {
+	local $_ = shift;
+	my $encoding = shift || 'utf-8';
+	s/([^-a-zA-Z0-9!*+\/])/sprintf("=%02X", ord($1))/eg;
+	s/(.*)/=\?$encoding\?q\?$1\?=/;
+	return $_;
+}
+
 # use the simplest quoting being able to handle the recipient
 sub sanitize_address
 {
@@ -643,8 +659,7 @@ sub sanitize_address
 
 	# rfc2047 is needed if a non-ascii char is included
 	if ($recipient_name =~ /[^[:ascii:]]/) {
-		$recipient_name =~ s/([^-a-zA-Z0-9!*+\/])/sprintf("=%02X", ord($1))/eg;
-		$recipient_name =~ s/(.*)/=\?utf-8\?q\?$1\?=/;
+		$recipient_name = quote_rfc2047($recipient_name);
 	}
 
 	# double quotes are needed if specials or CTLs are included
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index e222c49..a4bcd28 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -210,4 +210,19 @@ test_expect_success '--compose respects user mime type' '
 	! grep "^Content-Type: text/plain; charset=utf-8" msgtxt1
 '
 
+test_expect_success '--compose adds MIME for utf8 subject' '
+	clean_fake_sendmail &&
+	echo y | \
+	  GIT_EDITOR=$(pwd)/fake-editor \
+	  GIT_SEND_EMAIL_NOTTY=1 \
+	  git send-email \
+	  --compose --subject utf8-sübjëct \
+	  --from="Example <nobody@example.com>" \
+	  --to=nobody@example.com \
+	  --smtp-server="$(pwd)/fake.sendmail" \
+	  $patches &&
+	grep "^fake edit" msgtxt1 &&
+	grep "^Subject: =?utf-8?q?utf8-s=C3=BCbj=C3=ABct?=" msgtxt1
+'
+
 test_done

-- 
1.5.5.rc1.133.g360d
Teemu Likonen· Mar 26, 2008, 09:23 UTC · re: Jeff King · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

Jeff King kirjoitti (26.3.2008 klo 4.39):
Show 12 quoted lines
> On Wed, Mar 26, 2008 at 10:30:33AM +0200, Teemu Likonen wrote:
> 
> > I had missed the --cover-letter option completely. It may be useful
> > too. I'm still trying to find the best way to send pathces. If
> > I send intro message with real MUA I either need to wait for the
> > message to show up on a mailing list or check my sent-mail folder to
> > find the Message-Id. Once I know the Message-Id I can send the
> > actual patch series with 'git send-email' as replies to the intro
> > message. Well, this is OK.
> 
> That is how I used to do it; now I use --cover-letter (which you
> probably missed because it is brand new in the upcoming 1.5.5).

I'm using the current 'master' branch so --cover-letter is there. Managed to miss it anyway. :)

Hmm, do you send the 0000-cover-letter.patch with 'git send-email'? It seems that this cover letter don't get MIME headers when sent that way. Sending through 'mutt -H' it works fine but then the Message-Id needs to be copy-pasted manually to send-mail for the rest of the series (to have them appear as replies, that is). No problem with that.

> OK, I will add it to the end of my long todo. Out of curiosity, do you
> actually want something besides utf-8, or is this just to make us feel
> feature complete?

I mostly use (and promote) UTF-8 and now that I begin to understand how send-email works I can live with the current behaviour just fine. Don't take my feedback as complaining. :)

In general my interests are in human languages and I have done quite a lot of work in different areas to make computers interact nicely with human languages. This is my interest in general level and I tend to report/fix problems when I notice them. From Git's point of view at the present moment we can probably say just like you did: "make us feel feature complete."

Thanks for your work on this. Really.
Jeff King· Mar 26, 2008, 09:35 UTC · re: Teemu Likonen · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

On Wed, Mar 26, 2008 at 11:32:31AM +0200, Teemu Likonen wrote:
Show 5 quoted lines
> I mumbled:
> 
> > Thanks for your work on this. Really.
> 
> My English is somewhat broken. I meant to thank you for your work.

Maybe it is the late hour, but I am a native English speaker, and it parsed just fine to me.

-Peff
Jeff King· Mar 26, 2008, 09:33 UTC · re: Teemu Likonen · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

On Wed, Mar 26, 2008 at 11:23:03AM +0200, Teemu Likonen wrote:
Show 5 quoted lines
> Hmm, do you send the 0000-cover-letter.patch with 'git send-email'? It
> seems that this cover letter don't get MIME headers when sent that way.
> Sending through 'mutt -H' it works fine but then the Message-Id needs to
> be copy-pasted manually to send-mail for the rest of the series (to have
> them appear as replies, that is). No problem with that.
No, I have format-patch do the threading. So something like:
  git format-patch --cover-letter --thread --stdout upstream >mbox
  mutt -f mbox

and then in mutt I bind a key to <resend-message>. For each message, I do the 'resend', set the recipient headers, look it over one last time, and then send. The most annoying part is entering the recipients; usually it isn't too bad because I have short aliases for Junio and the list, but I had to, e.g., cut and paste your address twice for the other series.

Probably munging the 'to:' and 'cc:' before running mutt would make the most sense, but I haven't gotten around to it yet.

> I mostly use (and promote) UTF-8 and now that I begin to understand how
> send-email works I can live with the current behaviour just fine. Don't
> take my feedback as complaining. :)

OK, I am inclined to leave the patches as-is, then, and wait for somebody to complain about their pet encoding. My reasoning is that:

  - in most cases throughout git, we assume things are happening in
    utf-8, so I don't think it will come as a great surprise
  - I think doing it right might be more complex than just send-mail; I
    am thinking there might need to be a "stuff the user inputs is in
    encoding X" config option. And I don't want to do the work. :)
> Thanks for your work on this. Really.

No problem at all. Thank you for helping make git better with bug reports!

-Peff
Jeff King· Mar 27, 2008, 07:38 UTC · re: Jeff King · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

On Wed, Mar 26, 2008 at 05:33:10AM -0400, Jeff King wrote:
Show 6 quoted lines
> No, I have format-patch do the threading. So something like:
> 
>   git format-patch --cover-letter --thread --stdout upstream >mbox
>   mutt -f mbox
> 
> and then in mutt I bind a key to <resend-message>. For each message, I

Since it looks like you are using mutt also, I will warn you that there is a problem with this workflow: when mutt does the resend, it generates a new message-id. Thus the patches are all connected in a thread because they all in-reply-to the cover letter, but the cover letter is not connected, since it has a new message-id.

I'm not sure if there is a way to fix this short of patching mutt. :(
-Peff
Todd Zullinger· Mar 27, 2008, 19:44 UTC · re: Jeff King · lore

Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters

Jeff King wrote:
Show 8 quoted lines
> Since it looks like you are using mutt also, I will warn you that
> there is a problem with this workflow: when mutt does the resend, it
> generates a new message-id. Thus the patches are all connected in a
> thread because they all in-reply-to the cover letter, but the cover
> letter is not connected, since it has a new message-id.
> 
> I'm not sure if there is a way to fix this short of patching mutt.
> :(
I don't know if it would help, but perhaps you could try:
:set postponed=/path/to/your/format-patch-mbox

instead of opening the mbox using -f, and then recall the messages to send. That *might* prevent mutt from rewriting the message-id, but I haven't tested it at all.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Between two evils, I always pick the one I never tried before.
    -- Mae West

← back to recent threads