Subject: Re: Empty 5322.From address or 5322.From address containing <>
From: Dave CROCKER <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Dave CROCKER <[email-masked]>, "Sonneveld, Rolf" <[email-masked]>, [email-masked]
Date: Fri, 16 Apr 2010 10:50:00 -0700
List-Id: <ietf-822.imc.org>

On 4/16/2010 10:16 AM, Arnt Gulbrandsen wrote:
> On 04/16/2010 04:31 PM, Dave CROCKER wrote:
>> I'm not seeing it allowed in the ABNF:
>
> Via quoted-string. You end up with
> From: Ex Ample <""@example.com>
> I suppose you could say it's not empty any more once quoted.

Not really.  It's empty.  I missed that.

Seems like a specification bug.

and it was in 822...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 16 Apr 2010 19:16:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
Organization: Me, http://arnt.gulbrandsen.priv.no
To: [email-masked]
Cc: Dave CROCKER <[email-masked]>, "Sonneveld, Rolf" <[email-masked]>, [email-masked]
Subject: Re: Empty 5322.From address or 5322.From address containing <>
Sender: [email-masked]

On 04/16/2010 04:31 PM, Dave CROCKER wrote:
> I'm not seeing it allowed in the ABNF:

Via quoted-string. You end up with
   From: Ex Ample <""@example.com>
I suppose you could say it's not empty any more once quoted.

Arnt

Date: Fri, 16 Apr 2010 09:53:14 -0700
To: "Sonneveld, Rolf" <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Empty 5322.From address or 5322.From address containing <>
Cc: [email-masked]
Sender: [email-masked]

Hi Rolf,
At 01:56 16-04-10, Sonneveld, Rolf wrote:
>The real problem here is that mail software from a recipient, that 
>validates the headers of a message, might reject the message, which 
>means a double-bounce (as we're talking here about invalid headers 
>of notification messages causing a reject). For instance the mail 
>adapter in SAP is such an SMTP server implementation which reject 
>these type of messages at the end of the DATA phase, after the 
>single dot. And we can't really blame SAP for this, after all why do 
>we have standards?

The rejection at the end of the DATA phase won't cause the SMTP 
server to generate a bounce.  The DSN is generated by the SMTP 
sender.  There are two possible problems.  I'll use Section 6.4 of 
RFC 5321 for the easier one which is invalid headers:

   'Unfortunately, variations, creative interpretations, and outright
    violations of Internet mail protocols do occur'

   'The debate as to whether a well- behaved SMTP receiver or relay
    should reject a malformed message, attempt to pass it on unchanged,
    or attempt to repair it to increase the odds of successful delivery
    (or subsequent reply) began almost with the dawn of structured
    network mail and shows no signs of abating.  Advocates of rejection
    claim that attempted repairs are rarely completely adequate and that
    rejection of bad messages is the only way to get the offending
    software repaired.  Advocates of "repair" or "deliver no matter what"
    argue that users prefer that mail go through it if at all possible
    and that there are significant market pressures in that direction.'

The second possibility is discussed in RFC 3464.

Regards,
-sm

Date: Fri, 16 Apr 2010 07:31:47 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Arnt Gulbrandsen <[email-masked]>
CC: "Sonneveld, Rolf" <[email-masked]>, [email-masked]
Subject: Re: Empty 5322.From address or 5322.From address containing <>
Sender: [email-masked]

On 4/16/2010 1:28 AM, Arnt Gulbrandsen wrote:
>
> On 04/16/2010 10:02 AM, Sonneveld, Rolf wrote:
>> in the header of the notification mail. Please note: the above From is
>> the header From (5322.From), not the envelope From (5321.From). Are the
>> above From: header lines valid according to RFC822/2822/5322?
>
> No.
>
> I've seen a lot of other invalid hacks, too. The only one I've seen
> that's syntactically legal is From: ""@[], which may have syntax going
> for it, but I do find it somewhat lacking in charm.
>
>> It seems to me they are not valid, as from RFC5322 I get the impression
>> that a From address at least should contain an "@" and a localpart and a
>> domainname, and even if localpart and domainname would be allowed to be
>> empty, there's still the "@" sign...
>
> The localpart can be empty (IMO that's highly inadvisable, but it is
> legal).

I'm not seeing it allowed in the ABNF:

     addr-spec       =   local-part "@" domain

     local-part      =   dot-atom / quoted-string / obs-local-part

     dot-atom-text   =   1*atext *("." 1*atext)

     dot-atom        =   [CFWS] dot-atom-text [CFWS]

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: "Sonneveld, Rolf" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Date: Fri, 16 Apr 2010 10:56:00 +0200
Subject: Re: Empty 5322.From address or 5322.From address containing <>
Sender: [email-masked]

=3Cdiv style=3D=22font-size=3A 16px=3B font-family=3A =27times new roman=
=27=22=3E=3Cdiv=3EHi=2C Arnt=2C=3C/div=3E=3Cdiv=3E=3Cbr/=3E=3C/div=3E=3C=
div=3EOn 16-04-10=2C =3Cb class=3D=22name=22=3EArnt Gulbrandsen =3C/b=3E=
=26lt=3Barnt=40gulbrandsen=2Epriv=2Eno=26gt=3B wrote=3A=3C/div=3E=3Cbloc=
kquote cite=3D=22mid=3A4BC81FA0=2E1060704=40gulbrandsen=2Epriv=2Eno=22 c=
lass=3D=22iwcQuote=22 style=3D=22padding-left=3A 13px=3B margin-left=3A =
0px=3B border-left=3A =2300f 1px solid=22 type=3D=22cite=22=3EOn 04/16/2=
010 10=3A02 AM=2C Sonneveld=2C Rolf wrote=3A=3Cbr /=3E=26gt=3Bin the hea=
der of the notification mail=2E Please note=3A the above From is=3Cbr /=3E=
=26gt=3Bthe header From (5322=2EFrom)=2C not the envelope From (5321=2EF=
rom)=2E Are the=3Cbr /=3E=26gt=3Babove From=3A header lines valid accord=
ing to RFC822/2822/5322=3F=3Cbr /=3E=3Cbr /=3ENo=2E=3Cbr /=3E=3Cbr /=3EI=
=27ve seen a lot of other invalid hacks=2C too=2E The only one I=27ve se=
en that=27s syntactically legal is From=3A =26quot=3B=26quot=3B=40=5B=5D=
=2C which may have syntax going for it=2C but I do find it somewhat lack=
ing in charm=2E=3Cbr /=3E=3Cbr /=3E=26gt=3BIt seems to me they are not v=
alid=2C as from RFC5322 I get the impression=3Cbr /=3E=26gt=3Bthat a Fro=
m address at least should contain an =26quot=3B=40=26quot=3B and a local=
part and a=3Cbr /=3E=26gt=3Bdomainname=2C and even if localpart and doma=
inname would be allowed to be=3Cbr /=3E=26gt=3Bempty=2C there=27s still =
the =26quot=3B=40=26quot=3B sign=2E=2E=2E=3Cbr /=3E=3Cbr /=3EThe localpa=
rt can be empty (IMO that=27s highly inadvisable=2C but it is legal)=2E=3C=
/blockquote=3E=3Cdiv=3E=3Cbr/=3E=3C/div=3E=3Cdiv=3E=3Cdiv=3Ethanks a lot=
 for your fast response! The messages which had these invalid From addre=
sses came (as far as I could trace from the headers) from SurfControl an=
d Websense appliances=2E It seems Websense bought Surfcontrol in the pas=
t=2C so=2E=2E=2E=3C/div=3E=3Cdiv=3E=3Cbr/=3E=3C/div=3E=3Cdiv=3EThe real =
problem here is that mail software from a recipient=2C that validates th=
e headers of a message=2C might reject the message=2C which means a doub=
le-bounce (as we=27re talking here about invalid headers of notification=
 messages causing a reject)=2E For instance the mail adapter in SAP is s=
uch an SMTP server implementation which reject these type of messages at=
 the end of the DATA phase=2C after the single dot=2E And we can=27t rea=
lly blame SAP for this=2C after all why do we have standards=3F=3C/div=3E=
=3Cdiv=3E=A0=3C/div=3E=3Cdiv=3EIs there any =27822 validator=27 tool or =
organization that can certfy mail servers and appliances=2C like there i=
s the W3C validator tool=3F If we can=27t prevent vendors from releasing=
 software that violates the standards=2C we might be able to give a posi=
tive impuls to the making of standards-based software by giving=A0vendor=
s=2C who release software that implements RFC5322 properly=2C the chance=
 to certify their software=2E=3C/div=3E=3Cdiv=3E=A0=3C/div=3E=3Cdiv=3E/r=
olf=3C/div=3E=3C/div=3E=3C/div=3E

Date: Fri, 16 Apr 2010 10:28:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
Organization: Me, http://arnt.gulbrandsen.priv.no
To: "Sonneveld, Rolf" <[email-masked]>
Cc: [email-masked]
Subject: Re: Empty 5322.From address or 5322.From address containing <>
Sender: [email-masked]

On 04/16/2010 10:02 AM, Sonneveld, Rolf wrote:
> in the header of the notification mail. Please note: the above From is
> the header From (5322.From), not the envelope From (5321.From). Are the
> above From: header lines valid according to RFC822/2822/5322?

No.

I've seen a lot of other invalid hacks, too. The only one I've seen 
that's syntactically legal is From: ""@[], which may have syntax going 
for it, but I do find it somewhat lacking in charm.

> It seems to me they are not valid, as from RFC5322 I get the impression
> that a From address at least should contain an "@" and a localpart and a
> domainname, and even if localpart and domainname would be allowed to be
> empty, there's still the "@" sign...

The localpart can be empty (IMO that's highly inadvisable, but it is legal).

Arnt

From: "Sonneveld, Rolf" <[email-masked]>
To: [email-masked]
Date: Fri, 16 Apr 2010 10:02:54 +0200
Subject: Empty 5322.From address or 5322.From address containing <>
Sender: [email-masked]

=3Cdiv=3E=3Cfont face=3D=22Arial=22 size=3D=222=22=3EHi=2C=3C/font=3E=3C=
/div=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22 /=3E=3C/p=3E=3Cp=
=3E=3Cfont face=3D=22Arial=22 size=3D=222=22=3Eit seems there are a numb=
er of appliances out on the Internet which generate (in situations where=
 they cannot deliver the message) a non-delivery notification containing=
 an empty From address=3A=3C/font=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Ari=
al=22 size=3D=222=22 /=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=
=222=22=3EFrom=3A=3C/font=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 si=
ze=3D=222=22 /=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22=
=3Eor a non-empty From address that looks like the envelope From for NDN=
s=3A=3C/font=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22 =
/=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22=3EFrom=3A =26=
lt=3B=26gt=3B=3C/font=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=
=222=22 /=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22=3Ei=
n the header of the notification mail=2E Please note=3A the above From i=
s the header From (5322=2EFrom)=2C not the envelope From (5321=2EFrom)=2E=
 Are the above From=3A header lines valid according to RFC822/2822/5322=3F=
=3C/font=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22 /=3E=
=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22=3EIt seems to m=
e they are not valid=2C as from RFC5322 I get the impression that a From=
 address at least should contain an =26quot=3B=40=26quot=3B and a localp=
art and a domainname=2C and even if localpart and domainname would be al=
lowed to be empty=2C there=27s still the =26quot=3B=40=26quot=3B sign=2E=
=2E=2E=3C/font=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22=
 /=3E=3C/p=3E=3Cp=3E=3Cfont face=3D=22Arial=22 size=3D=222=22=3E/rolf=3C=
div=3E=3Cbr /=3E=3C/div=3E=3C/font=3E=3C/p=3E=3Cdiv=3E=3Cbr /=3E=3C/div=3E