RFC 6692

Source Ports in Abuse Reporting Format (ARF) Reports

📅 published July 2012, from ietf

Source Ports in Abuse Reporting Format (ARF) Reports 🎀

RFC 6692 💖

  • Authors: Richard Clayton (University of Cambridge) and Murray S. Kucherawy (Cloudmark, Inc.) 👯‍♀️
  • Category: Standards Track 🔥
  • Date: July 2012 🌸
  • Updates: RFC 6591 ✨
  • ISSN: 2070-1721 🦋

Abstract

okay so this doc adds one extra header field to ARF reports 📨 so you can figure out the source port of the connection behind an abuse incident 🕵️‍♀️ it's giving detective energy, fr 💅

This document also updates RFC 6591 🫶

Status of This Memo

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF) and it totally represents the consensus of the IETF community 👑 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅 if you want more info on Internet Standards, check out Section 2 of RFC 5741 📚

for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6692 🦋

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date it was published 📜 please actually read these, bestie, because they explain your rights and restrictions 🙈 any Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚

Table of Contents

1. Introduction ....................................................2
2. Keywords ........................................................2
3. Source-Port Field Definition ....................................2
4. Time Accuracy ...................................................3
5. IANA Considerations .............................................3
6. Security Considerations .........................................3
7. References ......................................................4
   7.1. Normative References .......................................4
   7.2. Informative References .....................................4
Appendix A. Acknowledgements .......................................5

1. Introduction ✨

okay so [ARF] defined the Abuse Reporting Format 📨 it's an extensible message format for Email Feedback Reports, and they're used to report email abuse 🚫 then [AUTHFAILURE-REPORT] extended ARF so you could report email authentication failures 🔐 both specs let you include the source IP address in a report 📍 but as [LOG] explains, once IP address sharing techniques are in play, you need source port values in reports too if you want to unambiguously pin down where the abuse came from 🎯 no cap, that's the whole plot 💀

so this document defines an ARF reporting field to hold that info, and it gives guidance on how to use it 🌸

2. Keywords

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS] 🧚 these are the official requirement-level words, so they're doing a lot of work 💅

3. Source-Port Field Definition 🦋

there's a brand-new ARF header field called "Source-Port" ✨ when it's present in a report, it MUST contain the client port of the TCP connection that the reported message came from 🔌 it lines up with the "Source-IP" field, which holds the client address of that same connection, so together they completely describe where the abuse came from 💖 main character energy for sure 👑

per [ABNF], the formal syntax looks like this 📝

  source-port = "Source-Port:" [CFWS] 1*5DIGIT [CFWS] CRLF

"CFWS" (email-style comments or folding white space) gets imported from [MAIL] 🎀

when any report includes the "Source-IP" field (see Section 3.2 of [ARF]), this field SHOULD also be there, unless the port number isn't available 🙈 and using this field is RECOMMENDED for reports generated per [AUTHFAILURE-REPORT] (see Section 3.1 of that document) 🫶

4. Time Accuracy ⏰

[LOG] really stresses how important accurate clocks are when you're generating reports with source port info 🕰️ the reason is that source ports can get recycled super fast in Internet Service Provider environments 😭 the same considerations described there apply here too 🔥

report generators that include an Arrival-Date report field MAY choose to express that date in Universal Coordinated Time (UTC) 🌍 this makes it way easier to match things up with local records at sites following the provisions of [LOG] 💜

5. IANA Considerations 📋

IANA has added this entry to the "Feedback Report Header Fields" registry 🍓

Field Name:  Source-Port

Description:  TCP source port from which the original message was
   received

Multiple Appearances:  No

Related "Feedback-Type":  any

Reference:  [RFC6692]

Status:  current

6. Security Considerations 🔐

this extension doesn't introduce any new security considerations that aren't already covered in [ARF] 🛡️

some security considerations about source port logging in general can be found in [LOG] 👀 go read those, they're the real tea 🍵

7. References 📚

7.1. Normative References

  • [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 💅
  • [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010. 📨
  • [AUTHFAILURE-REPORT] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012. 🔐
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
  • [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. 💌

7.2. Informative References

  • [LOG] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011. 🌸

Appendix A. Acknowledgements 🫶

the authors want to thank the following folks for reviewing this proposal and giving constructive criticism: Steve Atkins, Scott Kitterman, John Levine, and Doug Otis 💖

the idea for this work started within the Messaging Anti-Abuse Working Group (MAAWG) 🧚

Authors' Addresses 💌

Richard Clayton
University of Cambridge
Computer Laboratory
JJ Thomson Avenue
Cambridge  CB3 0FD
United Kingdom

Phone: +44 1223 763570
EMail: richard.clayton@cl.cam.ac.uk


Murray S. Kucherawy
Cloudmark, Inc.
128 King St., 2nd Floor
San Francisco, CA 94107
US

Phone: +1 415 946 3800
EMail: superuser@gmail.com

that's the whole spec, bestie 🌈✨

📦 where this page comes from