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/
