Tobias Herkula wrote in <fr3p281mb29746d82adb6c32db205e024ea...@fr3p281mb2974.deup281.prod.OUTLO\ OK.COM>: |I think the current idea is to have dedicated unique signatures for \
That is not my idea. |every mail-from/rcpt-to combination and that's the reason for going \ |down to a single RCPT-TO. A spammer therefore cannot reuse a message \ Now you turned a cycle and justify what you claimed was your own desire with a reasoning from that other draft. You must agree this is a bit of a twilight, is it. |and "replay" it to other recipients. And it's not about single transaction \ |vs multiple transactions, it's about single a single RCPT-TO per transac\ |tion vs multiple RCPT-TOs per transaction. It's still totally fine \ |to send multiple emails with the help of RSET on a single open connection. \ But you totally missed the point. The point is that this draft mutilates SMTP that has the capability to address a lot of RCPT TO in a single transaction to a single transaction. And your desire turns out to be what was reasoning in that draft, so it is a very fresh desire and it seems to have had no actual reason from driving your email system. Logical. No no, ACDC can that *without* mutilating SMTP, if such desire / capability is announced by the receiver, and only then. Just like what was posted on this list in the past. You only have to send per receiver *domain*, not per receiver. That is, actually, what naturally happens within an SMTP server. |This will also not break any forwarding, as the second idea is that \ |every hop also signs with a new signature for every unique mail-from/rcp\ |t-to combination that comes out of a forward configuration. This will \ More or less. But from within the DKIM v1 infrastructure that is. |essentially create a signed forward path that allows every involved \ |hop to determine if they think the message is spam. This makes "replay" \ They can do whatever they want just as now. |"impossible" as a side effect. But it also makes it possible to bounce \ It is a dedicated feature. |back via the recorded return path to the last hop and therefore solves \ |the privacy issue that exists today, as we would prevent "bouncing" \ |to the initial mail-from and therefore disclosing forwards to the initial \ |sender. ACDC relies on SMTP and the delivery status notification. If you have reserved months of development time to implement that DKIM2, you can very well reserve one month to slice in ACDC and implement that SMTP feature, shall you not already support it. |BCC is also not an issue as this does not impact the handling. As the \ |initial mail-from is known to BCC recipients anyway and the rcpt-to \ |is now limited to one and would also only contain the individual BCCed \ |recipient. Not it is not. I and ACDC will not penaltize normal SMTP, nor will be massively penaltize non-integrated systems like postfix, or exim, or opensmtpd, for the sake of highly integrated computing clusters like likely Google and what not. SMTP can support multiple RCPT TO, and it is absolutely sufficient to sort emails per receiver domain, which benefits all those masses of mailing-lists which have to deal with plenty of subscribptions of mass providers like Gmail for example. SMTP is I/O bound, and reducing this I/O noise is a massive win. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
