Re: sieve - "malformed email address"es - space at EOL?
- Date: Fri, 11 Aug 2017 21:41:02 +1000
- From: Zenaan Harkness <zenaan@xxxxxxxxxxxx>
- Subject: Re: sieve - "malformed email address"es - space at EOL?
On Fri, Aug 11, 2017 at 11:03:20AM +0100, Darac Marjal wrote:
> On Fri, Aug 11, 2017 at 01:14:21PM +1000, Zenaan Harkness wrote:
> > Any sieve gurus?
> > (YES, I finally made it off of procmail, and sieve is AWEsome in
> > comparison - oh happy days :)
> > So two sieve failures (dodgy incoming emails got through gmail)
> > exposed themselves in relation to sieve in the last few days as
> > follows:
> > 1)
> > The first is simply a "superfluous" space char at the end of the line
> > on the "From:" line, as follows (ignore leading spaces):
> > From: "EFA" <memberadmin@xxxxxxxxxx>⋅
> > Note the deceptively cheeky little space char at the end of the line
> > - and yes, either EFA or some middle man has a dodgy MUA/ mail
> > processing agent.
> > QUESTION:
> > Why is a single space at this EOL, so malformed as to cause sieve to
> > spit the dummy with an error?
> According to RFC5322 (which obsoleted RFC2822, which obsoleted RFC822), the from field is defined as:
> from = "From:" mailbox-list CRLF
> mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
> mailbox = name-addr / addr-spec
> name-addr = [display-name] angle-addr
> angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
> obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS])
> (addr-spec is an email address). So, the simplest parsing of that line is as a single mailbox where display-name is
> EFA (That is, display-name is actually ' "EFA" ', but the spaces are optional whitespace within the quoted-string and
> the quotes delimit the content), and the remainder is an angle-addr. Angle-addr DOES, as you can see, allow for CFWS
> (Comment and/or Folding White Space) after the closing angle bracket.
> So, I would say that the From header *is* RFC compliant and you should consider raising a bug.
That's "fully guru, man, fully guru!" :D
> > 2)
> > The dodgiest "To:" line I have literally ever seen, as follows:
> > To: <Undisclosed-Recipient:;>
> > Notice the colon, AND the semi colon, in this "email address".
> This is allowed by RFC 6854 (March 2013), which updates RFC5322 to allow "Group Syntax" in the From and Sender fields.
> RFC5322 already allowed group syntax in To, Cc, BCc etc fields. Groups consist of:
> group = display-name ":" [group-list] ";" [CFWS]
> group-list = mailbox-list / CFWS / obs-group-list
> In other words, they consist of a display name, then a colon, then a list of mailboxes and a final semi-colon. The
> list of mailboxes is optional, so here we have a group called "Undisclosed-Recipient" with no members. Or, in other
> words, this message is not addressed to anybody (it's probably been blind-copied to others, though).
> RFC 6854, in allowing group syntax in the From Field allows one to say "This message is not from anyone" or "This
> message is from a group of authors" and, in theory, should mean that no-one needs to use "noreply@xxxxxxxxxxx" or
> "directors@xxxxxxxxxxx" as a From address.
Sounds like I'm running an implementation of sieve which is a bit
behind the times.
> > Again gmail passed it right through.
> > I can actually accept this failure of sieve to pass the email through
> > - such an addy is indeed rather egregious.
> > BUT, it would be nice to have sieve actuallly OUTPUT the actual
> > problematic email address, and to this end, does anyone know some
> > magical incantation to add to sieve, so I can see all problematic
> > (and only the problematic) lines of incoming emails, as "error
> > output" by sieve to the cmd line?
> This depends on your implementation of sieve. Dovecot's implementation, Pigeonhole, will log to ~/.dovecot.sieve.log
> by default.
Hmm. Gnu mailutils. Seems it's a little out of date with the RFCs,
failing to e.g. detect "Undisclosed-Recipient:;" AND balking on a
harmless space char ... perhaps it's designed to only work well
assuming some other mailutils pre-processing.
Oh well, try dovecot-sieve it is.
Thank you very much.
> For more information, please reread.
:) - Great .sig