On Wed 30/Mar/2022 19:37:27 +0200 Brotman, Alex wrote:
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.
https://www.ietf.org/archive/id/draft-brotman-srds-01.txt
https://datatracker.ietf.org/doc/html/draft-brotman-srds-01
I think the last paragraph in Security Considerations doesn't belong there.
Additionally, as the message resulting in a 259 response is accepted
by the remote system, there should not be an NDR to notify the sender
that their messages have been regarded as spam.
AIUI, it says it spares the sender the need to produce an NDR. I that case, it
should go to Section 5.2.
However, in some cases —when the message is not bulk— an NDR-like thing would
be useful, so the sender can text the recipients to look in their spam folders.
The (non capitalized) should must not be understood as a prohibition to do that.
As for the code/ extended status question, I agree that shortage of digits
demands to think twice before allocating one. However, while the dotted format
introduced by RFC 3463 enjoys the boundlessness of natural numbers, those
tokens are difficult to understand, often inexact and not universally supported.
In case 259 is not going to be used, I'd suggest to experiment with keywords
rather than with extended status code. To wit, when writing regular
expressions to catch specific responses, I'd find it much easier to write
something like:
/^.*courieresmtp: id[^,]*,from=[^,]*,addr=[^>]*>:.2\d\d.*\bMAYBESPAM\b/
rather than:
/^.*courieresmtp: id[^,]*,from=[^,]*,addr=[^>]*>:.2\d\d.2\.[67]\.1[123]?/
And I'd guess the former would be much more reliable than the latter.
Best
Ale
--
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp