RBE email address not injected when mailbox exceeds 64 characters for non-PHPMailer mail plugins

[boonebgorges]

The Postman SMTP plugin https://wordpress.org/plugins/postman-smtp/ uses a Zend library for email address validation. In IMAP mode, RBE's Reply-To address fails this validation, because the local part of the address is too long. RBE's AES-encrypted query string is 64 characters long, which, when appended to the 'tag' portion of the email address, will always exceed the 64-character maximum specified by RFC 5321 https://tools.ietf.org/html/rfc5321#section-4.5.3 See https://github.com/wp-plugins/postman-smtp/blob/master/Postman/Postman-Mail/Zend-1.12.10/Validate/EmailAddress.php#L553

I can hack around this for the time being by hardcoding an exception into the Postman SMTP plugin. (For this project, SMTP + IMAP are non-negotiable, due to institutional policies.) But it'd be nice to work around it in a more straightforward way from the RBE end.

It looks like I can probably disable AES encryption in favor of something non-secure like base-64 encoding for the purposes of this project. But I thought perhaps you had some thoughts about a cryptographically-sound option that generates a shorter hash.

As a side note, the documentation/code around the bp_rbe_encode_mode filter is a bit confusing. If you filter to something other than 'aes', not only does no encryption take place, but an empty string (actually, false) is returned from the function, so that the Reply-To address is something like reply+@gmail.com. Maybe this is by design, because you shouldn't be sending these params unencrypted, but it could probably use some explanatory inline text. :-D

[r-a-y]

RBE's AES-encrypted query string is 64 characters long, which, when appended to the 'tag' portion of the email address, will always exceed the 64-character maximum specified by RFC 5321

Yeah, I had to workaround the character limitation for PHPMailer:

• Commit f297579
• Commit f7831e8

Github's RBE also suffers from the same character problem.

If you filter to something other than 'aes', not only does no encryption take place, but an empty string (actually, false) is returned from the function, so that the Reply-To address is something like reply+@gmail.com. Maybe this is by design

Not by design. This is a bug :)

But I thought perhaps you had some thoughts about a cryptographically-sound option that generates a shorter hash.

Good idea, would need to do a bit of research here to figure out if this is possible.

[r-a-y]

If you filter to something other than 'aes', not only does no encryption take place, but an empty string (actually, false) is returned from the function, so that the Reply-To address is something like reply+@gmail.com. Maybe this is by design

I'm looking at the code now and this is by design 😄

The doc for the 'bp_rbe_encode_mode' filter could be a little clearer, but if you set the mode to something else like:

add_filter( 'bp_rbe_encode_mode', function( $retval ) {
   return 'base64';
} );

You still have to override the 'bp_rbe_encode' and 'bp_rbe_decode' filter to actually change the querystring to use base-64.

Something like:

add_filter( 'bp_rbe_encode', function( $retval, $string, $mode, $key, $param ) {
    return base64_encode( $string );
}, 10, 5 );

add_filter( 'bp_rbe_decode', function( $retval, $string, $mode, $key, $param ) {
    return base64_decode( $string );
}, 10, 5 );

[boonebgorges]

Yup, that's basically what I've done as a proof-of-concept. It just wasn't clear from the variable names especially - `$encrypt` and `$decrypt` versus, maybe, `$encrypted` and `$decrypted`.

…

On 04/18/2017 12:05 PM, r-a-y wrote: If you filter to something other than 'aes', not only does no encryption take place, but an empty string (actually, false) is returned from the function, so that the Reply-To address is something like ***@***.*** ***@***.***>. Maybe this is by design I'm looking at the code now and this is by design 😄 The doc for the |'bp_rbe_encode_mode'| filter could be a little clearer, but if you set the mode to something else like: |add_filter( 'bp_rbe_encode_mode', function( $retval ) { return 'base64'; } ); | You still have to overrride the |'bp_rbe_encode'| and |'bp_rbe_decode'| filter to actually change the querystring to use base-64. Something like: |add_filter( 'bp_rbe_encode', function( $retval, $string, $mode, $key, $param ) { return base64_encode( $string ); }, 10. 5 ); | |add_filter( 'bp_rbe_decode', function( $retval, $string, $mode, $key, $param ) { return base64_decode( $string ); }, 10. 5 ); | — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#96 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPDY6vC8_cFoE6QEN6x-kLvSYH4qimRks5rxO1ngaJpZM4NAg4L>.

[r-a-y]

But I thought perhaps you had some thoughts about a cryptographically-sound option that generates a shorter hash.

About generating a shorter, crypto hash, that isn't really possible.

If we remove the crypto, then using a technique like the following will shorten the querystring by ~50% from AES:
http://stackoverflow.com/a/2996326

[boonebgorges]

I ended up switching to an SMTP plugin that isn't so finicky about the Reply-To address (bonus: it doesn't override wp_mail(), so we get to take advantage of BP emails). So the question isn't urgent for me. But thank you for putting thought into this!