Hello,
This draft wasn't suggesting that the receiving system reject the mail when
detected as spam, but instead accept the message and notify the sender via a
new reply code. I believe this suggests the document should have a
"rationale" section as to why a receiver may want to do this.
As for the case when there are two recipients, how does your method of
suggesting alternate means of communication work when there are two recipients?
Do you do this at RCPT, or DATA? If at DATA, do you provide multiple contacts
for multiple recipients?
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
-----Original Message-----
From: Дилян Палаузов <dilyan(_dot_)palauzov(_at_)aegee(_dot_)org>
Sent: Friday, January 14, 2022 2:31 PM
To: Brotman, Alex <Alex_Brotman(_at_)comcast(_dot_)com>; ietf-smtp <ietf-
smtp(_at_)ietf(_dot_)org>
Subject: Re: [ietf-smtp] SMTP Response for Detected Spam (SRDS)
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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bro
tman-
srds/__;!!CQl3mcHX2A!XA124SMuI4FySNhEBK2jsYwEcbtskGN_1AaqMprtcXNt
gBMid4FJGqKN0PpmaWV08Rhc$
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-brot
man-srds-
00.txt__;!!CQl3mcHX2A!XA124SMuI4FySNhEBK2jsYwEcbtskGN_1AaqMpr
tcXNtgBMid4FJGqKN0PpmaVSQea0h$
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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf
-
smtp__;!!CQl3mcHX2A!XA124SMuI4FySNhEBK2jsYwEcbtskGN_1AaqMprtcXNtgB
Mid4FJGqKN0PpmaXrdnUu9$
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp