Hello Alex,
I personally inject my incoming emails into anti-spam software. The
software gives some reasoning (static, dynamic analysis), if it thinks
the email is spam. Then I reject the mails during the SMTP dialog and
return the reasoning of the anti-spam filter in the SMTP-reply. The
SMTP-reply includes further means to contact me.
The advantage is, that I have no Spam/Junk folder, which needs
attention. The advantage is, that nobody ever asks, why a particular
email was evaluated as spam.
Additional reply code does not help. In fact SMTP needs three reply
codes an total - 2, 4 and 5.
In the next ten years, the 259 code will not be used to notify the
sender about anomalies. If the sender shall be notified in a backward
compatible manner about anomalies in the delivery, a 4xx or 5xx code
must be used. Accepting a mail and returning 5xx code at the same time
will not find consensus here.
My recommendation is, if a mail is rejected because it is evaluated as
spam, include in the rejection lines alternative means to contact the
recipient, if the recipient does want so.
You have to think on the case, where an email for two recipients is
considered as spam to the first recipient and as ham for the second.
This problem is not addressed in your draft and discussing it here will
again not get any traction.
Greetings
Дилян
On Fri, 2022-01-14 at 15:34 +0000, Brotman, Alex wrote:
Hey folks,
I had originally sent this over to dispatch, though Murray and John
felt it better to discuss here. I thought it might help the general
ecosystem if there were a method by which receivers could give an in-
line response to a sender that the message they're attempting to
deliver is believed to be spam/malicious. Additionally, I thought it
would be good to create a new code so that it could be more easily
identified by the sending party. While I understand there's some
fear that this could be misused by spammers, restricting it
responsible parties may help there, and it could help responsible
parties identify abusive parties within their platform more quickly.
https://datatracker.ietf.org/doc/draft-brotman-srds/
https://www.ietf.org/archive/id/draft-brotman-srds-00.txt
It's rather short (the only sample I found was also rather short),
but I welcome comments or thoughts. Thanks for your time.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp