On 4/11/2025 1:00 PM, Richard Clayton wrote:
> *DKIM has nothing to do with bounces. Really. Nothing.*
> Nothing 'requires' rejection at SMTP transaction time.
Perhaps you could explain how backscatter is avoided if you do not
reject at SMTP transaction time ? We give one example of how you can
currently avoid it, but it makes assumptions that do not always hold
The topic is DKIM.
How is backscatter a DKIM issue?
> Rejection at transaction time merely moves the question of sending a
bounce
>from
> the server SMTP, after the session, to the client SMTP,
contemporaneously with
> the session. Or also after it.
yes, but presumably the client SMTP system has some reason for believing
it should be handling the email in the first place -- so it is far
better placed in deciding whether a DSN is appropriate
I don't understand your premise or conclusion.
But, again, how is this relevant to work on DKIM?
> In the overall, global model of multi-handler email, this
distinction is pretty
> minor. It might be deemed significant only in a highly constrained,
single-hop
> scenario. But even then, well...
interesting this point this not garner a response.
> So, the model is a per-hop signing sequence that is used in reverse
to send
> bounces back through every /relay/ that handled the message?
> *This is quite a fragile operational model.*
why is it fragile when the cryptography gives assurance as to which
entities are taking some "responsibility" for the email ?
Your logic escapes me.
> Note that source routing has been largely deprecated in modern
networking, yet
> this scheme relies on it.
it is retracing the outgoing path -- so it is not source routing
It builds and then uses one.
>> If you want to create a privacy preserving forwarding service, you
>> need to SRS rewrite the email's bounce address so that bounces
don't
>> accidentally leak the real address of the recipient.
> This is presented in a fashion that does not adequately describe the
context
> for the concern.
we should definitely make our document longer in due course
But, sure, let's embrace the effort to solve this problem, before we
discuss what the problem is and why it should be solved.
> To suggest a more complete foundation and to test whether I
understand what is
> intended:
> When a message is re-posted, such as by an aliasing or mailing list
> service, the original author will not necessarily know the address
> of the final recipient. If there is desire to keep the original
> author from knowing that (new) address, then a bounce message
> created during this later processing MUST NOT have the original
> RFC5321.Mail-From return address. Otherwise, the original author
> might see this later recipient address in the bounce email.
yes, that's what we are on about
As noted previously, -- but not responded to -- this is solved by having
the system creating the new addressee replace the SMTP Mail From address.
Unless, of course, the new recipient does a reply...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
