On 5 Mar 2025, at 21:19, Murray S. Kucherawy wrote:
> On Wed, Mar 5, 2025 at 3:54 PM Steffen Nurpmeso wrote:
>
>> But that DKIM2 draft mutilates SMTP to *only* work in this one
>> recipient mode: even if a mailing-list has hundreds of Gmail
>> subscribers, where ACDC would (could) send one messag
Murray and I threw together a quick agenda for the meeting, basically
consisting of administrivia from us followed by Bron leading discussion
of the documents that appear in the charter (now split into 3 instead of
2). It's posted in the datatracker. There should be plenty of time to
discuss WG
Lots of fair points for discussion in this. Please keep in mind that the
people working on this have been working on it for a bit, and it becomes
easy to unintentionally treat details as obvious or not worth mentioning
after repeated iterations. I don't think any omissions are being made
intentiona
On Wed, Mar 5, 2025 at 1:08 PM Michael Thomas wrote:
> I've been reading the draft mentioned in the charter re: replay and
> rcpt-to and don't understand why that changes anything wrt replay. If
> there is a message that a spammer has discovered passes a recipient's
> spam filter, what difference
On Wed, Mar 5, 2025 at 3:54 PM Steffen Nurpmeso wrote:
> But that DKIM2 draft mutilates SMTP to *only* work in this one
> recipient mode: even if a mailing-list has hundreds of Gmail
> subscribers, where ACDC would (could) send one message to all of
> those in a single transaction, DKIM2 sends hu
Just so you're aware: I am going to be pretty slammed between now and
the IETF meeting (I stupidly volunteered for the ICANN NomCom and will
be in Seattle tomorrow through next Thursday for the ICANN meeting), and
Murray is still being an Area Director. That means that we're unlikely
to be able
Tobias Herkula wrote in
:
|I'm part of that SMTP audience and I'm looking forward to reducing \
|the number of RCPT-TOs in a transaction to one. I also think of the \
Reasons. Give me just one reason! I have mailing-lists myself,
and lots of gmail addresses. All of these are bundled. (In
se
A few points:
1) A sender or intermediate can already send a new message per rcpt-to.
This is an operational issue, and has nothing to do with DKIM. Indeed,
lots of transactional mail already does this so you unsubscribe, etc.
2) In the case of a typical mailing list, for example, the origina
Michael Thomas wrote in
<1dbce124-0e1c-4f05-b827-60025684e...@mtcc.com>:
|On 3/5/25 12:29 PM, Tobias Herkula wrote:
...
|I've been reading the draft mentioned in the charter re: replay and
|rcpt-to and don't understand why that changes anything wrt replay. If
|there is a message that a spam
Steffen Nurpmeso wrote in
<20250304225608.jcbQ5EUD@steffen%sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20250304221133.VfKY5pqy@steffen%sdaoden.eu>:
||Steffen Nurpmeso wrote in
|| <20250304205330.GtAvvE5w@steffen%sdaoden.eu>:
...
|It is more than that.
|I find it sheer unbelievable that such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <20250305184412.8asro9Ar@steffen%sdaoden.eu>, Steffen
Nurpmeso writes
>And not to talk about the possible privacy issues if such a DKIM2
>header escapes into the wild, shall
>
> | rt=| RFC5321.rcpt-to
>but also
> | mf=
As we prepare for the WG's first meeting in Bangkok later this month, the
current (Pete) and soon-to-be (me) chairs would like to ask if there's
anyone that will be attending who's willing to be a scribe and who might be
willing to act as notetaker, to save us from spending time arranging this
duri
I think the current idea is to have dedicated unique signatures for 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 and "replay" it to other
recipients. And it's not about single transaction vs multiple tran
I'm part of that SMTP audience and I'm looking forward to reducing the number
of RCPT-TOs in a transaction to one. I also think of the joy of having a
cryptographic signature that covers MAIL-FROM and RCPT-TO in addition to the
already covered headers and the body of an email. Bringing up privac
On 3/5/25 12:29 PM, Tobias Herkula wrote:
I'm part of that SMTP audience and I'm looking forward to reducing the number
of RCPT-TOs in a transaction to one. I also think of the joy of having a
cryptographic signature that covers MAIL-FROM and RCPT-TO in addition to the
already covered headers
Richard Clayton wrote in
:
|-BEGIN PGP SIGNED MESSAGE-
|Hash: SHA1
|
|In message <20250305184412.8asro9Ar@steffen%sdaoden.eu>, Steffen
|Nurpmeso writes
|
|>And not to talk about the possible privacy issues if such a DKIM2
|>header escapes into the wild, shall
|>
|>| rt=|
Tobias Herkula wrote in
:
|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 just
Section 1:
1. verifying the path that messages have taken to get to it,
including by being able to reverse modifications or by asserting
that it trusts the previous hop unconditionally.
First off, "unconditionally" seems like a very strong word especially
wrt "trust
On 3/5/25 3:12 PM, Steffen Nurpmeso wrote:
Michael Thomas wrote in
<1dbce124-0e1c-4f05-b827-60025684e...@mtcc.com>:
|On 3/5/25 12:29 PM, Tobias Herkula wrote:
...
|I've been reading the draft mentioned in the charter re: replay and
|rcpt-to and don't understand why that changes anythin
Michael Thomas wrote in
<799da3ac-0b80-4aa4-857d-25d1b1027...@mtcc.com>:
|A few points:
|
|1) A sender or intermediate can already send a new message per rcpt-to.
|This is an operational issue, and has nothing to do with DKIM. Indeed,
|lots of transactional mail already does this so you uns
Michael Thomas wrote in
<64aaf30f-c5ca-42a3-8ee6-730d7d98e...@mtcc.com>:
|On 3/5/25 3:12 PM, Steffen Nurpmeso wrote:
|> Michael Thomas wrote in
|> <1dbce124-0e1c-4f05-b827-60025684e...@mtcc.com>:
|>|On 3/5/25 12:29 PM, Tobias Herkula wrote:
|> ...
|>|I've been reading the draft mentioned
21 matches
Mail list logo
