Spam reporting

Last updated

Spam reporting, more properly called abuse reporting, is the action of designating electronic messages as abusive for reporting to an authority (e.g. an email administrator) so that they can be dealt with. Reported messages can be email messages, blog comments, or any kind of spam.

Contents

Flagging user generated content in web sites

Abuse reports are a particular kind of feedback whereby users can flag other users' posts as abusive content. Most web sites that allow user-generated content either apply some sort of moderation based on abuse reports, such as hiding or deleting the offending content at a defined threshold, or implement a variety of user roles that allow users to govern the site's contents cooperatively. [1]

Email spam reporting

Spammers' behavior ranges from somehow forcing users to opt in, to cooperatively offering the possibility to opt out, to wildly hiding the sender's identity (including phishing). The most intractable cases can be dealt by reporting the abusive message to hash-sharing systems [2] like, for example, Vipul's Razor for the benefit of other victims. In some cases, there may be a cooperative component on the sender side who will use spam reports to fix or mitigate the problem at its origin; for example, it may use them to detect botnets, [3] educate the sender, or simply unsubscribe the report's originator. Email spam legislation varies by country, forbidding abusive behavior to some extent, and in some other cases it may be worth prosecuting spammers and claiming damages.

RFC 6650 recommends that recipients of abusive messages report that to their mailbox providers. The provider's abuse-team should determine the best course of action, possibly considering hash-sharing and legal steps. If the sender had subscribed to a Feedback Loop (FBL), the mailbox provider will forward the complaint as a feedback report according to the existing FBL agreement. [4] Otherwise, mailbox providers should determine who is responsible of the abuse and forward the complaint to them. Those recipients of unsolicited abuse reports are actually prospect FBL subscribers, inasmuch as the mailbox provider needs to offer them some means to manage the report stream. On the other hand, mailbox providers can prevent further messages from non-cooperative senders of abusive content. [5]

Abuse reports are sent by email using the Abuse Reporting Format (ARF), except for the initial notification by the recipient in cases where a mailbox implementation provides for more direct means. The target address of an abuse report depends on which authority the abusive message is going to be reported to. Choices include the following: [6]

  1. A public reporting hub, or global reputation tracker, such as SpamCop or Abusix's blackhole.mx. Different degrees of skill are required to properly interact with different hubs.
  2. The domain-specific reporting hub is the recommended choice for end users. [7] If provided, it should be accessible by a visible button or menu item in the mail client.
  3. A feedback loop subscriber can be selected as a target by a mailbox provider after receiving an end-user report. Users should be aware of their provider's policy.
  4. The abuse POC of an authenticated domain who handled the reported message. DomainKeys Identified Mail (DKIM) is the usual authentication protocol, [8] but Sender Policy Framework (SPF) can be used in the same way. A mailbox provider choice.
  5. The abuse POC for the IP address of the last relay. Some skill is required to properly locate such data. This is the default choice for a mailbox provider whose server had received the abusive message (before the recipient reported it) and annotated the relevant IP address. There are various sites who maintain POC databases, such as Network Abuse Clearinghouse (by name), Abusix (by IP address (number)), and more. There is also a hierarchy of delegations at the relevant Regional Internet registry (RIR), and each corresponding Whois record may include a POC, either as a remark or as a more specific database object, e.g. an Incident response team.

The first three methods provide for full email addresses to send reports to. Otherwise, target abuse mailboxes can be assumed to be in the form defined by RFC 2142 (abuse@example.com), or determined by querying either the RIR's whois databases—which may have query result limits [9] — or other databases created specifically for this purpose. There is a tendency to mandate the publication of exact abuse POCs. [10] [11]

Abused receivers can automate spam reporting to different degrees: they can push a button when they see the message, or they can run a tool that automatically quarantines and reports messages that it recognizes as spam. When no specific tools are available, receivers have to report abuse by hand; that is, they forward the spammy message as an attachment—so as to include the whole header—and send it to the chosen authority. Mailbox providers can also use tools to automatically process incidents notifications. [12]

See also

Related Research Articles

<span class="mw-page-title-main">Email</span> Mail sent using electronic means

Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.

<span class="mw-page-title-main">Open mail relay</span>

An open mail relay is a Simple Mail Transfer Protocol (SMTP) server configured in such a way that it allows anyone on the Internet to send e-mail through it, not just mail destined to or originating from known users. This used to be the default configuration in many mail servers; indeed, it was the way the Internet was initially set up, but open mail relays have become unpopular because of their exploitation by spammers and worms. Many relays were closed, or were placed on blacklists by other servers.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322. The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.

Various anti-spam techniques are used to prevent email spam.

Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain. This authentication only applies to the email sender listed in the "envelope from" field during the initial SMTP connection. If the email is bounced, a message is sent to this address, and for downstream transmission it typically appears in the "Return-Path" header. To authenticate the email address which is actually visible to recipients on the "From:" line, other technologies such as DMARC must be used. Forgery of this address is known as email spoofing, and is often used in phishing and email spam.

Sender ID is an historic anti-spoofing proposal from the former MARID IETF working group that tried to join Sender Policy Framework (SPF) and Caller ID. Sender ID is defined primarily in Experimental RFC 4406, but there are additional parts in RFC 4405, RFC 4407 and RFC 4408.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

<span class="mw-page-title-main">Message submission agent</span>

A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.

The Sender Rewriting Scheme (SRS) is a scheme for bypassing the Sender Policy Framework's (SPF) methods of preventing forged sender addresses. Forging a sender address is also known as email spoofing.

Sieve is a programming language that can be used for email filtering. It owes its creation to the CMU Cyrus Project, creators of Cyrus IMAP server.

WHOIS is a query and response protocol that is used for querying databases that store an Internet resource's registered users or assignees. These resources include domain names, IP address blocks and autonomous systems, but it is also used for a wider range of other information. The protocol stores and delivers database content in a human-readable format. The current iteration of the WHOIS protocol was drafted by the Internet Society, and is documented in RFC 3912.

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email, a technique often used in phishing and email spam.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing email, email scams and other cyber threat activities.

Email forwarding generically refers to the operation of re-sending a previously delivered email to an email address to one or more different email addresses.

A mailbox is the destination to which electronic mail messages are delivered. It is the equivalent of a letter box in the postal system.

<span class="mw-page-title-main">Feedback loop (email)</span> Process of forwarding user complaints to senders

A feedback loop (FBL), sometimes called a complaint feedback loop, is an inter-organizational form of feedback by which a mailbox provider (MP) forwards the complaints originating from their users to the sender's organizations. MPs can receive users' complaints by placing report spam buttons on their webmail pages, or in their email client, or via help desks. The message sender's organization, often an email service provider, has to come to an agreement with each MP from which they want to collect users' complaints.

The Abuse Reporting Format (ARF) also known as the Messaging Abuse Reporting Format (MARF) is a standard format for reporting spam via email.

A mailbox provider, mail service provider or, somewhat improperly, email service provider is a provider of email hosting. It implements email servers to send, receive, accept, and store email for other organizations or end users, on their behalf.

Murray S. Kucherawy is a computer scientist, mostly known for his work on email standardization and open source software.

References

  1. ↑ Felix Schwagereit; Ansgar Scherp; Steffen Staab (June 14–17, 2011). Survey on Governance of User-generated Content in Web Communities (PDF). WebSci'11. ACM . Retrieved 2012-01-04.
  2. ↑ "Hash-Sharing Systems". wiki. Apache Foundation . Retrieved 15 August 2012.
  3. ↑ Jason Livingood; Nirmal Mody; Mike O'Reirdan (March 2012). Recommendations for the Remediation of Bots in ISP Networks. IETF. doi: 10.17487/RFC6561 . RFC 6561 . Retrieved 15 August 2012.
  4. ↑ "Email Feedback Loop: What It Is and Why It Matters [2023]". mailtrap.io. 2023-03-01. Retrieved 2023-04-18.
  5. ↑ Murray Kucherawy, ed. (June 2012). Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF). IETF. doi: 10.17487/RFC6650 . RFC 6650 . Retrieved 28 June 2012. Rather than generating feedback reports themselves, MUAs SHOULD create abuse reports and send these reports back to their Mailbox Providers so that they can generate and send ARF messages on behalf of end users (see Section 3.2 of [RFC6449]). This allows centralized processing and tracking of reports, and provides training input to filtering systems.
  6. ↑ Theo Clarke (10 October 2005). "Finding network abuse contacts". Wikimedia Foundation . Retrieved 22 April 2011.
  7. ↑ John R. Levine (9 December 2009). "Adding a spam button to MUAs". ASRG mailing list (Mailing list). Retrieved 22 April 2011. See also the wiki summary of that mail thread.
  8. ↑ J.D. Falk, ed. (November 2011). Complaint Feedback Loop Operational Recommendations. IETF. doi: 10.17487/RFC6449 . RFC 6449 . Retrieved 18 November 2011. Appendix B. Using DKIM to Route Feedback
  9. ↑ "Community Consultation Underway - Removal of WHOIS Query Result Limit". ARIN. 2007-03-12. Retrieved 2009-09-28. [T]he ARIN WHOIS query limit of 256 results [...] has been in place since ARIN's inception as a means of curtailing data mining.
  10. ↑ Leslie Nobile (18 July 2011). "Abuse Contact To Be Mandatory per Policy 2010-14". announcements. American Registry for Internet Numbers . Retrieved 24 August 2011.
  11. ↑ Tobias Knecht (8 November 2010). "Abuse contact information". Asia-Pacific Network Information Centre . Retrieved 22 April 2011.
  12. ↑ One is Abusehelper
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.