Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Nov 22, 2016 at 7:45 AM, Michael Storz <[e-mail]> wrote:


>
>> The negative side of the proposal is the requirement to split all
>>> multi-recipient-emails to single-recipient-emails, which is a show
>>> stopper for me.
>>>
>>
>> That's curious; why?
>>
>
> Because SMTP is defined as a multi-recipient transport. If this extension
> would require a mandatory split of every message, then this has to be
> discussed at IETF-SMTP because the semantics of SMTP are changed. It is a
> big difference if the implementation of a mta decides to split all messages
> on arrival or if some ISPs decide to send only singe-recipient emails, or
> if a protocol extension requires mandatory splitting.
>

As I understand it, the vast majority of mail you receive is very likely
single-recipient, and the vast majority of what you send is probably the
same.  Operationally this wouldn't change much.  On my personal machine,
the distribution looks like this so far today:

  23 nrcpts=0,
 319 nrcpts=1,
  17 nrcpts=2,

So forcing 100% of those messages to be single-recipient would add 17 more
messages, or just under 5% of today's flow so far.  I don't have immediate
access to data from a larger source.

SMTP is not "defined" as a multi-recipient transport.  It supports that as
an option but doesn't require it.  At best this proposal establishes a
required profile of its use, but doesn't change any protocol fundamentals.
MTAs would not have to be reimplemented, though the things that pass
messages to the MSA might.

If a sender splits all emails because of some local advantage the sender
> forces the receiver to waist a lot of ressources for nothing. Instead of
> one message going through anti-spam several messages must be processed. For
> example, we are runnig amavisd+spamassassin in pre-queue mode to be able to
> reject spam on arrival (legal reasons). Splitting means we have to provide
> more ressources for parallel connections and/or to limit the number of
> connections per ip address or network which results in delayed messages.


That's true, but it doesn't change the SMTP model directly.  And given the
fact that statistically the vast majority of your mail is already
single-recipient, the cost you're concerned about here will likely be
minimal.  Or do you have contrary data?

I don't buy this argument. I would assume that every program which
> manipulates an email will use a library for this.
>

I don't think that's a valid assumption.  OpenDKIM happens to have the one
you cited, but in a pure sense no DKIM implementation actually needs it.
In fact OpenDKIM doesn't even really need it anymore now that it no longer
supports ADSP.  I should actually drop it.


> How high is the probability that a new sender or recipient header field
> will be registered? And even if that's the case, that's not a big problem.
> The program would treat the addresses as BCCs until the administrator
> changes the config to use the additional field or an update of the program
> would incorporate this field.
>

Betting on who will do what in the future hasn't served us well in the
past.  Either way, I'm talking about the standards here.  RFC6376 did a
more hand-wavy job of listing, for example, which header fields to sign
than RFC4871 did, because we can't predict what sorts of header fields
might be registered later.  Instead, we talked about the general theory of
what should be signed versus which specific fields are in and which are out.

-MSK

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html