ietf-822
[Top] [All Lists]

Re: Empty 5322.From address or 5322.From address containing <>

2010-04-16 04:06:59
Hi, Arnt,

On 16-04-10, Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> 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).

thanks a lot for your fast response! The messages which had these invalid From addresses came (as far as I could trace from the headers) from SurfControl and Websense appliances. It seems Websense bought Surfcontrol in the past, so...

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?
 
Is there any '822 validator' tool or organization that can certfy mail servers and appliances, like there is the W3C validator tool? If we can't prevent vendors from releasing software that violates the standards, we might be able to give a positive impuls to the making of standards-based software by giving vendors, who release software that implements RFC5322 properly, the chance to certify their software.
 
/rolf