On Mon, 12 Sep 2022, Brandon Long via mailop wrote:
On Mon, Sep 12, 2022 at 3:11 PM Jay Hennigan via mailop <mailop@mailop.org>
wrote:
Why has Google recently made so painfully difficult for the rest of the
Internet to make them aware of Gmail-originated spam?
Why do you think this is recent? AFAIK Google has never used abuse@
or postmaster@ addresses for useful spam reporting. Certainly the
majority of reports there have never been particularly useful.
Spam reports are only as useful as the reporter, and the reporting
is generally very suspect. The signal in the noise for those
addresses is small.
I mean, some of these are easy to ignore, but do you have hundreds
of users who go through every message in their spam label and
forward them to every possible abuse@ address for domains in the
message, and add the fbi and other three letter agencies as well?
Repeat, this is for messages we already marked as spam.
Now, maybe if more effort had been put into parsing that signal,
there would be more signal to be had... but we already have to fight
over abusive signups and attempted manipulation of web/imap/api spam
reporting,
A web form has the benefits of inheriting the usual spectrum of
abuse signals that web logged in users generate, and requiring
customers to provide the information that's actually needed.
If one were to use ARF reports, one might start by validating that
the reported message was actually sent by gmail, say by dkim
verifying it... which runs afoul of the attempts by places like
spamcop to prevent list washing by eliminating PII from reported
messages. Barring that, you'd need to keep an internal datastore
for all sent messages... which of course, is done by default (user's
mailboxes), but those can be deleted.
Is there an email header, along the lines of List-Unsubscribe:,
which directs mail clients how to report a message as spam ? The
"Spam-Report-URL" header could include a token which confirms that a
message was sent from Gmail and identifies which one.
I don't know the spamcop issue you mention so cannot say whether dkim
on this token would confirm that the message sent and the message
received are the same, but I don't see what would be gained by
attaching the token to a new message - using the URL directly would be
a more efficient way of triggering the denial of service attack *on the
original message*.
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
