SRS return path issues - causes whole email to fail to process

[eileenmcnaughton]

We have a new issue with mail components - the returnPath is capabil of being an invalid email in line with the Sender Rewriting scheme

e.g

Return-Path:  <SRS0=z9mA=EY=donate-long-name.example.org=b.51907682.51575594.57daed525aaca713@example.org>

However, this doesn't pass !filter_var( $value->email, FILTER_VALIDATE_EMAIL ) )

I'm playing catch up here a bit because I don't know why this wasn't raised in the context of #87 (our ref is https://lab.civicrm.org/dev/core/-/issues/3586)

However, the problem is that an SRS path - causes the whole email to fail to load - which is the problem

We have a proposed fix which is just to set NULL rather than throw an exception above in these cases - perhaps we can detect SRS in the string and just not return anything in that case?

[derickr]

Hi,

I'll have a look. I don't think there is anything wrong with this line, so moving to filter_var() with FILTER_VALIDATE_EMAIL was probably the wrong choice.

Do you have a set of emails that are now broken, and also your original broken one from the issue in civic that you linked to? We can then add these as test cases.

cheers,
Derick

[derickr]

I had a little dive into RFCs, and filter_var() does do this correctly. Local parts are limited to 64 octets, and your example "email address" has more.

I do think it is important that we validate this, and that we don't just return null when it isn't valid. I also believe that when parsing we should be more lenient in what we accept.

My suggestion would be to use the regex from PHP's filter_var() and extend the length limits. The PR at #91 does this, and extends it from 64 to 124.

[derickr]

I've merged this, and also released 1.9.6.

[eileenmcnaughton]

Thanks for being so helpful @derickr