Re: Updated draft for "SMTP Response for Detected Spam"

Alessandro Vesely <[email protected]> Fri, 1 Apr 2022 12:19:30 +0200
Newsgroups gmane.ietf.smtp
Message-ID <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp