Re: [ietf-smtp] homework, not an experiment, draft-crocker-email-deliver

Viktor Dukhovni writes:

> On Tue, Aug 03, 2021 at 08:25:11AM -0400, Sam Varshavchik wrote:
>
> > > Some abuse of Delivered-To to trigger bounces has been reported now and
> > > then, and the idea of obfuscated Delivered-To: had been discussed, but
> > > has not yet been implemented.  The freedom to do that some day remains.
> >
> > I don't see anything intrinsically wrong with this, by itself. It's better
> > than nothing. But if the actual goal is to prevent proxy DDOSes, this  
> should
> > be addressed directly: no bounce should be sent via SMTP for mail that was
> > accepted via SMTP.
>
> Getting rid of all after-queue bounces is too drastic a step.  It could
> some day prove necessary, but I don't think it is warranted at this
> time.  A more conservative change (already possible, but not enabled by
> default in Postfix) is to always include only the headers in bounces
> (text/rfc822-headers):
>
>     https://datatracker.ietf.org/doc/html/rfc3462#section-2
>
> That should have been the required format for bounces of EAI mail,
> obviating the need for the message/global (transfer-encoding of
> composite MIME parts) abomination.
This still leaves plenty of room for bandwidth amplification:

EHLO
MAIL FROM:<victim(_at_)domain(_dot_)com>
RCPT TO:<mailbox(_at_)example(_dot_)com>
DATA
Delivered-To: mailbox(_at_)example(_dot_)com
.

This gets returned with comparable SMTP commands, with minimal net change,  
there. But then extra bandwidth in terms of the message envelope from the  
bouncing mail server, a brief introduction containing the complaint that the  
Delivered-To: header already exists, a copy of this sole header, and MIME  
scaffolding.
That's going to be several degrees of magnitude larger than this sole  
header, for certain.

pgp1eWENLfbBD.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp