zbateson / mail-mime-parser

An email parser written in PHP
https://mail-mime-parser.org/
BSD 2-Clause "Simplified" License
458 stars 58 forks source link

ReceivedHeader: incorrectly detects the IP address #152

Closed mariuszkrzaczkowski closed 1 year ago

mariuszkrzaczkowski commented 3 years ago

IP discovery only works when the address is at the end, not as it is at the beginning an example for which it works

Received: from web.live.com ([124.236.173.16] helo=mail.live.com)

an example for which it doesn't work

Received: from web.live.com (helo=mail.live.com [124.236.173.16])

the problem is in regex https://github.com/zbateson/mail-mime-parser/blob/56792b40c12882a2d56e088e5bf0442d6e5a5e05/src/Header/Consumer/Received/DomainConsumer.php#L70-L82

mariuszkrzaczkowski commented 3 years ago

I proposed a solution to this problem in https://github.com/mariuszkrzaczkowski/mail-mime-parser/commit/882f89b7595c5210d1a0c18c3440dda57f5cf480

https://github.com/zbateson/mail-mime-parser/pull/153

zbateson commented 3 years ago

Hi @mariuszkrzaczkowski --

Unfortunately with the Received header it's a losing battle trying to parse every possibility. Please read through my thoughts on this issue: #78

The trouble is implementations for this header are all over the place, and besides covering the very basics of what the header is defined as in RFC 5321 section 4.4, I'm not convinced this library should attempt to parse much outside of that definition. In this case, the relevant part is:

From-domain    = "FROM" FWS Extended-Domain
Extended-Domain  = Domain /
                    ( Domain FWS "(" TCP-info ")" ) /
                    ( address-literal FWS "(" TCP-info ")" )

The trouble with your example is the 'helo=' part in the address, which is not valid according to that.

For example this test is testing exactly that, the domain part in front of the address:

https://github.com/zbateson/mail-mime-parser/blob/c59b9dcc7b6596826fbd0dacf7a39dbf97e9d90f/tests/MailMimeParser/Header/ReceivedHeaderTest.php#L52

mariuszkrzaczkowski commented 3 years ago

Do you have any idea to handle it universally? if others are doing it, it may be worth fighting. I can help

mariuszkrzaczkowski commented 3 years ago

we can add experimental or compliance mode or not and then try to handle such different cases in an additional mode

mariuszkrzaczkowski commented 3 years ago

I checked the last few messages and a lot is from IP at the beginning image

it's from big postal providers google, outlook

zbateson commented 3 years ago

My feeling on this is that I don't want mail-mime-parser chasing unstandardized formats -- think this or something like finding the 'reply' part of an email. There's just too much variation for a library like this, and it's not what I think it should be.

I'd encourage this to be outside of mail-mime-parser as an add-on for instance or something. Unfortunately at the moment mmp isn't very extensible, but I'm working on fixing that in a 2.0 so something like this could be created on the side and plugged in if someone wanted it... it's very slow going as I'm going through a busy period (fatherhood) and so haven't had much time to dedicate unfortunately.

mariuszkrzaczkowski commented 3 years ago

only how many servers are standards compliant ??? this is meant to be used and must be able to deal with every e-mail present only then the library can be used everywhere, this is my opinion

zbateson commented 3 years ago

The variation on Received headers is to the point that the format is 'unstandardized' imo, not that there are widely-used bad implementations. I'm happy to support mistakes in implementation so long as they're widely used and can't be fixed at the source.

Implementing support for Received (seems to me) to be an exercise in how much to support -- you can always find a new variation and need additional code added for it. I don't think that belongs here.