Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #185020 > unrolled thread

sieve - "malformed email address"es - space at EOL?

Back to article view | Back to linux.debian.user

Contents

  sieve - "malformed email address"es - space at EOL? Zenaan Harkness <zenaan@freedbms.net> - 2017-08-11 05:20 +0200
    Re: sieve - "malformed email address"es - space at EOL? Darac Marjal <mailinglist@darac.org.uk> - 2017-08-11 12:10 +0200
      Re: sieve - "malformed email address"es - space at EOL? Zenaan Harkness <zenaan@freedbms.net> - 2017-08-11 13:50 +0200
        Re: sieve - "malformed email address"es - space at EOL? David Wright <deblis@lionunicorn.co.uk> - 2017-08-11 15:30 +0200
          Re: sieve - "malformed email address"es - space at EOL? Zenaan Harkness <zenaan@freedbms.net> - 2017-08-11 15:40 +0200

#185020 — sieve - "malformed email address"es - space at EOL?

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@efa.org.au>⋅

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?



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".

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?

Manually reducing the lines being processed by sieve, running sieve
each time, till I finally figured out exactly which lines of which
emails is causing the problem, is quite the biatch TBH :)


TIA,
Zen

[toc] | [next] | [standalone]

#185029

[Multipart message — attachments visible in raw view] — view raw

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@efa.org.au>⋅
>
>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-angle-addr
   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.

>
>
>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@example.org" or "directors@example.com" as a From address.

>
>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. 

>
>Manually reducing the lines being processed by sieve, running sieve
>each time, till I finally figured out exactly which lines of which
>emails is causing the problem, is quite the biatch TBH :)
>
>
>TIA,
>Zen
>

-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#185035

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@efa.org.au>⋅
> > 
> > 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-angle-addr
>   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.

Thank you.

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@example.org" or
> "directors@example.com" 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

[toc] | [prev] | [next] | [standalone]

#185038

On Fri 11 Aug 2017 at 21:41:02 (+1000), Zenaan Harkness wrote:
> 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@efa.org.au>⋅
> > > 
> > > 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-angle-addr
> >   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.
> 
> Thank you.
> 
> That's "fully guru, man, fully guru!" :D

I'm having a little difficulty following this conversation,
particularly the bit about a "deceptively cheeky little space char".
I don't see a space at the end, but this character "⋅", ie

Character   ⋅
Character name	DOT OPERATOR
Hex code point 	22C5
Decimal code point	8901
Hex UTF-8 bytes 	E2 8B 85
Octal UTF-8 bytes 	342 213 205
UTF-8 bytes as Latin-1 characters bytes		â <8B> <85> 

so I have to ask whether you're reading this line in a font that is
lacking this character or makes it too small to see. I'm reading and
replying variously in neep, hack and h16 (all of these are monospace)
which all show it clearly as a centred dot (not easily distinguishable
from MIDDLE DOT, code point 00b7).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#185039

On Fri, Aug 11, 2017 at 08:20:02AM -0500, David Wright wrote:
> On Fri 11 Aug 2017 at 21:41:02 (+1000), Zenaan Harkness wrote:
> > 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@efa.org.au>⋅
> > > > 
> > > > 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-angle-addr
> > >   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.
> > 
> > Thank you.
> > 
> > That's "fully guru, man, fully guru!" :D
> 
> I'm having a little difficulty following this conversation,
> particularly the bit about a "deceptively cheeky little space char".
> I don't see a space at the end, but this character "⋅", ie
> 
> Character   ⋅
> Character name	DOT OPERATOR
> Hex code point 	22C5
> Decimal code point	8901
> Hex UTF-8 bytes 	E2 8B 85
> Octal UTF-8 bytes 	342 213 205
> UTF-8 bytes as Latin-1 characters bytes		â <8B> <85> 
> 
> so I have to ask whether you're reading this line in a font that is
> lacking this character or makes it too small to see. I'm reading and
> replying variously in neep, hack and h16 (all of these are monospace)
> which all show it clearly as a centred dot (not easily distinguishable
> from MIDDLE DOT, code point 00b7).

Ah yes, that would be from mutt - displaying such chars as dots.

Sorry about that.

In my incoming-email file it's actually a space.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web