I wanted to use a code for some of the reasons below. I would like to avoid a
sender to having to guess at what the response means, whether it be a
standard/extended code. Senders (of all sorts) have to do entirely too much of
that already. Some receivers are intentionally vague, and then senders are
left wondering if it's a me/you problem, or something else entirely. I've seen
several presentations about how someone is using ML to try to infer what the
MBP means. Hopefully this makes it easier to get helpful information.
As for the use case, the primary driver is to provide feedback to senders
(again, of all sorts) so if they can recognize they're doing something bad,
they may be able to lessen the abuse. I'm not overly worried about divulging
the information to malicious actors. If it were an ESP, I'd hope they can
either identify a spammer in their platform, or fire one who appears to be
doing testing (and I’m not sure what kind of logs they share with customers
anyway). For an MBP, it's not likely that the sender/customer would get a
notification of a successful delivery. There's a section in the draft that
talks about only using this with "trusted" partners/senders via some sort of
ACLs. I wouldn't imagine a MBP would use 259 with a netblock assigned to a
wireless carrier's end-user space for example.
John, I see your point about defining the extension. The receiver can't
respond 259 (if this were deployed at large) unless they're reasonably sure the
sender will treat it properly (as a successful delivery).
Thanks so far folks, much appreciated.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
-----Original Message-----
From: John Levine <johnl(_at_)taugh(_dot_)com>
Sent: Wednesday, March 30, 2022 2:08 PM
To: ietf-smtp(_at_)ietf(_dot_)org
Cc: Brotman, Alex <Alex_Brotman(_at_)comcast(_dot_)com>
Subject: [EXTERNAL] Re: [ietf-smtp] Updated draft for "SMTP Response for
Detected Spam"
It appears that Brotman, Alex <Alex_Brotman(_at_)comcast(_dot_)com> said:
Hey folks,
I wanted to send an update for this draft. I received (negative)
feedback from one person via the list, though several outside of the list
were
supportive. I wanted to try to clear up some of the language in the draft.
Appreciate feedback from those who are interested to read.
I'm still not thrilled but anyway
It needs to define an SMTP extension so servers know that they can reply 259
rather than 250 at the end of data, e.g.
ehlo cruddy.mail.org
250-sceptical.server.com
250-STARTTLS
250-PIPELINING
250-ENHANCEDSTATUSCODES
250 MAYBESPAM
mail from:<sleazy(_at_)sleazy(_dot_)org> MAYBESPAM
250 2.1.0 Sender accepted.
rcpt to:<someone(_at_)somewhere(_dot_)org>
250 2.1.0 Recipient accepted.
Although there used to be server replies that contained strings for the
client to
parse, they're all obsolete and these days clients only look at the three
digit
status code and the three part extended status code.
Don't have a great suggestion for how else to encode it other than maybe a
range of enhanced status codes 2.6.20 through 2.6.29 for spam scores 0/10 to
9/10.
R's,
John
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp