Re: SMTP Response for Detected Spam (SRDS)

Hello Alex,

I do not suggest anything about emails with two recipients, where the
first recipient wants to receive the email and the second does not.

This can be solved by implementing “Per Recipient Delivery Response”,
as LMTP has it - communicate after end of DATA for each recipient,
whether the recipients accepts the email.  This is good, but not
implemented.

Another approach is after the first RCPT TO: to temporary reject the
emails for all others RCPT TO:, which have different preferences from
the first recipient.  This way each email has practically one
recipient.

Greetings
  Дилян 

On Tue, 2022-01-18 at 13:22 +0000, Brotman, Alex wrote:
> 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: Дилян Палаузов <[email protected]>
> > Sent: Friday, January 14, 2022 2:31 PM
> > To: Brotman, Alex <[email protected]>; ietf-smtp <ietf-
> > [email protected]>
> > 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
> > > [email protected]
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf
> > > -
> > smtp__;!!CQl3mcHX2A!XA124SMuI4FySNhEBK2jsYwEcbtskGN_1AaqMprtcXNtgB
> > Mid4FJGqKN0PpmaXrdnUu9$
> 

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp