Fix email validation to prevent silent truncation with newline characters

[koshilife]

Summary

Fixed a data integrity issue where email addresses containing newline characters (\n, \r\n) were incorrectly validated as true due to silent truncation in the split_local_host method.

Problem

The original regex /(.+)@(.+)/ would match only up to the first \n character, causing silent data loss:

# Before fix
"user@foo.com\nother@bar.com" → Local: "user", Host: "foo.com" → Valid ❌
"a@example.com\nb@example.com" → Local: "a", Host: "example.com" → Valid ❌

This created a data integrity risk where invalid input appeared as valid email addresses.

Solution

Changed the regex in split_local_host method to use anchors:

# Before
if (lh = email.match(/(.+)@(.+)/))

# After  
if (lh = email.match(/\A(.+)@(.+)\z/))

The \A and \z anchors ensure the entire string must match the email pattern. If newline characters are present, the regex fails to match, and the method returns [email, ""], causing validation to fail appropriately.

Changes

• Core fix: Modified regex in Address.split_local_host method (1 line change)
• Test coverage: Added comprehensive test cases for newline character scenarios

Test Cases Added

def test_newline_characters
  assert !EmailAddress.valid?("user@foo.com\nother@bar.com") # LF truncation
  assert !EmailAddress.valid?("user@foo.com\r\nother@bar.com") # CRLF truncation  
  assert EmailAddress.valid?("\nuser@foo.com") # valid because strip processing removes \n
  assert EmailAddress.valid?("user@foo.com\r\n") # valid because strip processing removes \n
end

Verification

Before fix:

EmailAddress.valid?("user@foo.com\nother@bar.com") # => true ❌

After fix:

EmailAddress.valid?("user@foo.com\nother@bar.com") # => false ✅

Backward Compatibility

• ✅ All existing functionality preserved
• ✅ No breaking changes to valid email address handling
• ✅ Only affects invalid input that was previously incorrectly accepted

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

---

Note: This fix addresses a data integrity issue where malformed input was silently truncated and incorrectly validated. The change ensures that only complete, well-formed email addresses are accepted as valid.

[afair]

Thank you! The failing build is my fault, and I have the fix for that I will apply first. I'll merge this when it is ready

[koshilife]

@afair Thanks for reviewing quickly!

[koshilife]

I re-checked it myself, and the test failed. This PR may not be good enough yet.

[koshilife]

I've pulled the changes from ffb5a63, re-run the tests locally, and confirmed the fix. Please review it whenever you have a moment.