--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
-----Original Message-----
From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
Sent: Thursday, January 13, 2022 12:54 PM
To: Brotman, Alex <Alex_Brotman(_at_)comcast(_dot_)com>
Cc: Murray S. Kucherawy <superuser(_at_)gmail(_dot_)com>;
ietf-smtp(_at_)ietf(_dot_)org
Subject: Re: SMTP Code for Undesirable Messages
(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.
Ah, okay, thank you. That certainly helps.
* 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.
The receiving site can optionally choose to not give this response, or give it
only in certain situations. I understand the hesitancy though. If the site
admin were to deem it too dangerous or believes it leaks too much data, that's
understandable. Hopefully the MTA authors would provide a configuration flag.
However, there could be situations where notifying the sender could help them
fight abuse coming from their system. Today, many platforms do this already,
though usually without accepting the messages. We routinely see sites that say
they're rejecting a message due to questionable content.
For example, taken from logs:
"Permanent failure: 554-10 BAYES_99 BODY: Bayesian spam probability is 99 to
100%\r\n554-[score: 1.0000]\r\n554-0.2 BAYES_999 BODY: Bayes spam probability
is 99.9 to 100%\r\n554-[score: 1.0000]\r\n554-2.5 MDAEMON_SPF_SOFTFAIL MDaemon:
soft-failed SPF verification\r\n554-0.8 HTML_FONT_LOW_CONTRAST BODY: HTML font
color similar to\r\n554-background\r\n554-0.0 HTML_90_100 BODY: Message is 90%
to 100% HTML\r\n554-1.0 MIME_HTML_MOSTLY BODY: Multipart message mostly
text/html MIME\r\n554-0.1 HTML_TAG_EXIST_TBODY BODY: HTML has \"tbody\"
tag\r\n554-0.0 T_KAM_HTML_FONT_INVALID Test for Invalidly Named or
Formatted\r\n554-Colors in HTML\r\n554-0.8 RDNS_NONE Delivered to internal
network by a host with no rDNS\r\n554-1.0 FONT_INVIS_POSTEXTRAS Invisible text
+ suspicious URI\r\n554-0.0 NORDNS_LOW_CONTRAST No rDNS + hidden text\r\n550
5.6.0 Sorry, message looks like SPAM to me\r\n"
The difference would be that the receiver would still accept the message, and
(ideally) wouldn't divulge as much information. This is meant to formalize a
response where the receiver accepts the mail for delivery, though also notes
that they believe it to be spam and will route it accordingly.
* 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.
Understood. I'll polish it up a bit and send it into the ietf-smtp list.
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://urldefense.com/v3/__https://www.iana.org/assignments/smtp-
enha
nced-status-codes/sm__;!!CQl3mcHX2A!SBTilEV0esdxpIP59dB2Donw5EgS-
JHO2M
sRzjhkbt2S7UnMQtM3YJcKl9RYzCEAilFR$
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