(Note that, as Murray suggested, I've moved this response to the
SMTP list from DISPATCH. I obviously think that is good advice.
More inline.)
--On Thursday, January 13, 2022 15:06 +0000 "Brotman, Alex"
<Alex_Brotman=40comcast(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:
1. I'd asked someone who spends more time working within
the IETF, and dispatch was their suggestion. I'm happy to
take it anywhere else that is suggested.
2. I'm not
opposed to both. I suspect there will be a fair bit of
discussion about the general idea of the proposal, and this
had already crossed my mind. I would imagine there are some
MTAs that may not understand enhanced codes, though that may
mean they wouldn't know how to deal with any new response
codes at all.
Just some quick comments:
* For conventional response codes, RFC 5321 specifies exactly
how unrecognized codes are handled, so "wouldn't know how to
deal with..." is not possible for a conforming implementation.
A quick review of RFC 3463 (the Enhanced Status Code definition)
suggests it is less explicit but there is at least implicit
guidance there too. So I don't see that particular issue as a
problem.
* The bigger problem --one that, IIR, we discussed before what
became 5321 was completed -- is that a message identifying the
reason for rejection of an incoming message was a determination
that it was spam is that such a message would give the spammer
for too much information and would encourage retries with
modified messages in an attempt to beat the anti-spam system.
It is possible that things have changed and the idea would be
better received today but I would think that any proposal today
would have to address that issue.
* While a discussion on this list might be helpful, my
experience has been that the IETF is far better at dealing with
specific proposals in I-D form, even if it ends up changing them
significantly, than with more general discussions on mailing
lists. No suggestions about how you determine when the point
has been reached that a proposal in I-D form is needed, but you
should at least watch for symptoms of trying to create the
details of such a proposal in a mailing list discussion.
john
From: Murray S. Kucherawy <superuser(_at_)gmail(_dot_)com>
Sent: Wednesday, January 12, 2022 10:44 AM
To: Brotman, Alex <Alex_Brotman(_at_)comcast(_dot_)com>
Cc: dispatch(_at_)ietf(_dot_)org
Subject: Re: [dispatch] SMTP Code for Undesirable Messages
On Fri, Dec 17, 2021 at 9:05 AM Brotman, Alex
<Alex_Brotman=40comcast(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org<mailto:40comcast.co
m(_at_)dmarc(_dot_)ietf(_dot_)org>> wrote: I've been wondering if it may be
beneficial for a mailbox provider to be able to signal back to
the sender that the message is being accepted, but is
undesirable based on some criteria. The idea would be that a
provider may evaluate some characteristics of the message, and
before issuing a "250 Ok" have already determined the message
would be routed to the spam folder. Something as simple as:
255 Ok - Routing to spam folder
This would likely need some "Security Considerations" section
about how informing a malicious entity may be undesirable.
I'm willing to write this up as a proposed draft, though I'm
not entirely sure where to direct that draft. Thank you for
any advice you could provide.
Two things, one substantive and one procedural:
(1) On procedure: This might be better raised on either the
SMTP mailing list or the ART mailing list. DISPATCH is mostly
for talking about live or proposed work items, like when
there's a draft ready to bring to the table for disposition.
(2) On substance: Why not register an enhanced status code for
this instead of a new SMTP reply code? See
https://www.iana.org/assignments/smtp-enhanced-status-codes/sm
tp-enhanced-status-codes.xhtml<https://urldefense.com/v3/__htt
ps:/www.iana.org/assignments/smtp-enhanced-status-codes/smtp-e
nhanced-status-codes.xhtml__;!!CQl3mcHX2A!QZTAt9Rk-meQu68EGjOK
04SCXItePuipk4VkJXnY06PoqLxHr3flYy6-PsUqvno_cjMc$> and the RFC
it references.
-MSK
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp