Re: Postfix bounces arbitrary content

["Vincent Danen" <vdanen () redhat com>]

On 05/06/2014, at 19:57 PM, cve-assign () mitre org wrote:

> > take 5,000 randomly selected articles from my local news spool, and
> > cause b.com to bounce all of them from bob () b com to postmaster () a com.
> > This will likely cause a.com to block incoming mail from bob () b com,
> > or from all of b.com
>
> It seems more likely that the default configuration would produce
> bounce messages with a header From: address starting with
> "MAILER-DAEMON@" and an empty envelope-sender address. In that case,
> blocking mail from bob () b com wouldn't accomplish anything. But it's
> conceivable that the a.com administrator would start blocking the IP
> address of the b.com SMTP server.
>
> That's a detail that doesn't have much effect on the CVE inclusion
> question.
>
> Originating a new message to report non-delivery is valid according to
> RFC 2821 section 6.1. It's not really the case that there's inherently
> an integrity impact.
>
> There could be a Postfix developer announcement that, according to
> their security policy, this is unintended behavior with an integrity
> impact. A CVE assignment would be possible in that case.
>
> (To summarize: just because the RFC 2821 section 6.1 behavior is
> allowed doesn't mean that it's a good idea. An SMTP server should
> minimize the situations in which outsiders can trigger an arbitrary
> volume of outbound SMTP traffic to arbitrary destination IP addresses.
> Non-deliverability should be detected within the original SMTP dialog,
> and this case of the Delivered-To: header doesn't seem impossible to
> detect. However, there might be some type of architectural motivation
> for not checking the Delivered-To: header within the original SMTP
> dialog. Even if it was originally intentional, the developer might
> accept a feature request to change it.)

This is perfect.  Thank you.  It also confirmed what I expected (and upstream should have its say here).  I think that, 
given it was initially reported a decade ago, that that gives some hint as to how they may feel about it.

At any rate, thank you for your feedback.


-- 
Vincent Danen / Red Hat Security Response Team

Attachment: signature.asc
Description: OpenPGP digital signature