Andrew Ayer:
> On Sat, 23 Nov 2013 18:47:13 +0000
> Viktor Dukhovni <postfix-us...@dukhovni.org> 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
> 

Reply via email to