On Sun, Nov 20, 2022 at 11:08 AM Dave Crocker wrote:
> On 11/11/2022 7:19 AM, Murray S. Kucherawy wrote:
> > I think you've hit on possibly the most interesting part of this: In
> > RFC 6376, we said "You're taking some responsibility for this
> > message... and oh, by the way, it could get
On Sun, Nov 20, 2022, 11:08 Dave Crocker wrote:
> Seriously. DKIM is intended as a transit-time mechanism. When delivery
> occurs, transit is done. So DKIM has done its job and can (safely?) be
> removed.
One of the informational RFCs the original working group produced discussed
this. A
> On 20 Nov 2022, at 21:42, Dave Crocker wrote:
>
> On 11/20/2022 1:12 PM, Steve Atkins wrote:
>>> On 20 Nov 2022, at 20:48, Dave Crocker wrote:
>>>
>>> Remembering that you kicked this off with a heuristic approach, I'm merely
>>> noting that a BCC with an addressee listed in it should be
On 11/20/2022 1:12 PM, Steve Atkins wrote:
On 20 Nov 2022, at 20:48, Dave Crocker wrote:
Remembering that you kicked this off with a heuristic approach, I'm merely
noting that a BCC with an addressee listed in it should be just as valid (to
the heuristic) as having it occur in To: or CC:.
On 11/20/2022 1:07 PM, Jim Fenton wrote:
b) This assumes that the attackers (replayers) only have access to the messages
at delivery, and don’t operate their own MTAs. This is of course not a good
assumption.
Yes, that occurred to me. As of now, it seems clear we will find no
magic bullet.
> On 20 Nov 2022, at 20:48, Dave Crocker wrote:
>
> On 11/20/2022 12:31 PM, Steve Atkins wrote:
>>> On 20 Nov 2022, at 16:30, Dave Crocker wrote:
>>>
>>> On 11/10/2022 5:32 AM, Steve Atkins wrote:
A heuristic I’ve suggested previously is “If the recipient’s email address
is not in
On 20 Nov 2022, at 11:08, Dave Crocker wrote:
> On 11/11/2022 7:19 AM, Murray S. Kucherawy wrote:
>> I think you've hit on possibly the most interesting part of this: In RFC
>> 6376, we said "You're taking some responsibility for this message... and oh,
>> by the way, it could get replayed, and
On 11/20/2022 12:31 PM, Steve Atkins wrote:
On 20 Nov 2022, at 16:30, Dave Crocker wrote:
On 11/10/2022 5:32 AM, Steve Atkins wrote:
A heuristic I’ve suggested previously is “If the recipient’s email address is
not in the To: or Cc: header then treat the mail as unsigned”.
Even if it is
> On 20 Nov 2022, at 16:30, Dave Crocker wrote:
>
> On 11/10/2022 5:32 AM, Steve Atkins wrote:
>> A heuristic I’ve suggested previously is “If the recipient’s email address
>> is not in the To: or Cc: header then treat the mail as unsigned”.
>
> Even if it is showing in a (signed) BCC field?
On 11/11/2022 7:19 AM, Murray S. Kucherawy wrote:
I think you've hit on possibly the most interesting part of this: In
RFC 6376, we said "You're taking some responsibility for this
message... and oh, by the way, it could get replayed, and your claimed
responsibility extends to that case as
On 11/10/2022 4:54 AM, Laura Atkins wrote:
There are a couple of characteristics that stand out.
A few of the posting here have provided substantive details about the
nature of a replay attack. Not just the overall concept but some detail
about the means and methods.
Whatever draft(s)
By way of explaining why I have offered an alternative draft charter...
On 11/9/2022 4:08 AM, Barry Leiba wrote:
DKIM Working Group Charter
Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
using a digital signature to associate a domain identity with an email
message in a
Alternative draft charter text:
Domain Keys Identified Mail (DKIM, RFC 6376) associates a validated identifier with a
message. This aids receiver assessment of the message flow using that identifier,
improving reputation development and abuse detection. A DKIM-signed message can be
On 11/10/2022 5:32 AM, Steve Atkins wrote:
A heuristic I’ve suggested previously is “If the recipient’s email
address is not in the To: or Cc: header then treat the mail as unsigned”.
Even if it is showing in a (signed) BCC field?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
14 matches
Mail list logo
