On Mon, 2022-01-24 at 16:20 +0100, Tim van der Molen wrote: > Hi, > > Martijn van Duren (2022-01-23 20:13 +0100): > > > From: r...@relayclient.example.com (Cron Daemon) > > > > According to RFC5322 section 3.4[0] this is not a valid e-mail format. > > Just to point out this actually is valid. Text in parentheses is a > comment. See RFC 5322 section 3.2.2. Also this quote from section 3.4 > which describes the format used above: > > Note: Some legacy implementations used the simple form where the > addr-spec appears without the angle brackets, but included the > name of the recipient in parentheses as a comment following the > addr-spec. Since the meaning of the information in a comment is > unspecified, implementations SHOULD use the full name-addr form of > the mailbox, instead of the legacy form, to specify the display > name associated with a mailbox. Also, because some legacy > implementations interpret the comment, comments generally SHOULD > NOT be used in address fields to avoid confusing such > implementations. > > Best, > Tim
Thanks for pointing this one out, it made me take a closer look at the spec. So when I originally responded I was only thinking in terms of what characters are used in a domain name, but the " (Cron Daemon)" part is not to be interpreted as domain characters, but a CFWS (or comment folding whitespace). This means that it should not be returned by osmtpd_mheader_from_domain() as part of the domain. So it is valid syntax, but I shouldn't have returned it when comparing against the known domain list. Similarly there were also a couple of FWS that I could ignore. As for Paul's remark "SHOULD NOT" when it comes to this syntax: It's part of the current syntax (e.g. not obsolete), so I don't see any reason not to. Sorry for the confusion. I have the following changes lined up in my repo[0]: - Fix a couple of memory leaks in error paths (pointed out by Peter) - Add support for -D file, where file contains one domain per line. All other rules from -d apply. (requested by Mischa and Renaud) - Fix FWS and CFWS issues when parsing a domain (pointed out by Paul/Tim) If people could help me test the latest code (or even check the diffs of revision 75-HEAD) that would help prepare for a new release. martijn@ [0] http://imperialat.at/dev/filter-dkimsign/
