Re: [Fwd: Re: RFC 821] - ReadList.com

15 msg	Header for message size?
3 msg	address rewriting
2 msg	address_verify_relayhost and relay_domains
5 msg	pflogsumm reports
11 msg	Changing Queue IDs
3 msg	another authentication failure( with sasl)
2 msg	Bypass Spam checks for certain destinations
11 msg	Postfix 'too nice' with content_filter
7 msg	profiling a milter (dkim in particular)
7 msg	spammers tacking on headers how to block?

[Fwd: Re: RFC 821]
\ S. Highlander (19 Sep 2007)
. \ Victor Duchovni (19 Sep 2007)
. \ (Wietse Venema) (19 Sep 2007)
. . \ Alex Satrapa (20 Sep 2007)
. . . \ (Wietse Venema) (20 Sep 2007)
. . . . \ Mark Martinec (20 Sep 2007)
. . . \ mouss (20 Sep 2007)

1 msg	Re:
4 msg	(No Subject)
2 msg	RFC 821
7 msg	Suspending mail delievery to a specific user
2 msg	Re: OT - massive newsletter
12 msg	List management issue: possibly Off Topic
2 msg	bad protocol error Testing SASL configuration
2 msg	warning: smtpd_sasl_auth_enable is true, but SA...
1 msg	Quota Problem

Subject:	Re: [Fwd: Re: RFC 821]
Group:	Postfix-users
From:	mouss
Date:	20 Sep 2007

Alex Satrapa wrote:
> On 20/09/2007, at 02:48 , Wietse Venema wrote:
>
>>> strict_rfc821_envelopes
>
> The manual states what the effect of this option is:
>
> http://www.postfix.org/uce.html#strict_rfc821_envelopes
>
> In short: be prepared for stuff to break if you turn it on.

I second Wietse and Mark here. I never saw this break anything but few
crap.

Also, people use various programs that check addresses. accepting
randmly formatted addresses may cause serious problems or a lot of
efforts to guard against these problems.

or will you wait until a parsing bug is found in exchange (or other)
that lets attackers execute arbitrary code by crafting addresses?

>
> Turning on strict_rfc821_envelopes would seem to me to be breaking the
> spirit of Internet standards - "be liberal in what you accept, be strict
> in what you produce."

Those days are gone. Experience has shown that this "be liberal thing"
causes more harm than good. just compare xml and html.

Many vulnerabilities are caused by programs accepting broken content and
trying to guess, but the developper can't imagine all possible
variations so we endup with a vulnerability. and here, proxies,
firewalls, IDS,... can't help unless they know exactly how the
application parses the data, something not always available, and even if
available, you need to cope with every application parsing
implementation, instead of just one standard.

It's way more effective to require that bugs be fixed than let everybody
find its own workarounds, resulting in incompatibilities,
vulnerabilities, ... etc.

>
> My reading of the documents is that you should expect your server to
> refuse legitimate mail if you turn on this option.