Andrew Ayer:
> On Sat, 23 Nov 2013 18:47:13 +0000
> Viktor Dukhovni <[email protected]> wrote:
>
> > On Sat, Nov 23, 2013 at 10:20:19AM -0800, Andrew Ayer wrote:
> >
> > > The patch is simple and only touches two functions because most of the
> > > required pieces were already there. All I needed to do was split the
> > > argument list, parse the NOTIFY parameter (using the existing
> > > dsn_notify_mask() function), and pass the result as the last argument to
> > > cleanup_addr_bcc_dsn(), instead of always passing DEF_DSN_NOTIFY. I've
> > > tried to mimic the existing code style as much as possible.
> >
> > Simple context-free splitting is in principle not sufficient:
> >
> > RCPT TO:<"perverse NOTIFY=bad address"@example.com> NOTIFY=good
> >
> > Though the smtpd(8) parser for RCPT TO may not cover 100% of the
> > torture-test that is the RFC 5321 "RCPT TO" or "MAIL FROM" grammar,
> > it comes much closer... Look at extract_addr() in src/smtpd/smtpd.c.
>
> Thanks for taking a look at this.
>
> I'm actually only parsing RCPT TO ESMTP parameters here, not an entire
> RCPT TO command, and ESMTP parameter values are not allowed to contain
> space characters[1]. If a parameter value contains an address (e.g.
> ORCPT), then it's encoded using "xtext."[2] So I believe it should be
> quite sufficient to split on space character here.
That covers the syntax of all supported ESMTP parameters, so there
should be no problems syntax-wise. The code looks good. Maybe someone
else will find time to add ORCPT support later.
Wietse
> Regards,
>
> Andrew
>
> [1] https://tools.ietf.org/html/rfc1869#section-6 and
> http://tools.ietf.org/html/rfc5321#section-4.1.2
>
> [2] http://tools.ietf.org/html/rfc3461#section-4.2
>
