Source Ports in Abuse Reporting Format (ARF) Reports
RFC 6692
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Barry Leiba; former steering group member) Yes
(Pete Resnick; former steering group member) Yes
If you wanted to tighten up the syntax, you could do: source-port = "Source-Port:" [CFWS] 1*5DIGIT [CFWS] CRLF since a port number can't be more than 5 digits. But entirely up to you.
(Sean Turner; former steering group member) Yes
(Benoît Claise; former steering group member) No Objection
- Not really a DISCUSS but please consider the following comment (or please justify your choice) I looked at http://www.iana.org/assignments/marf-parameters/marf-parameters.xml for the Source-IP definition, and see: Source-IP: IPv4 or IPv6 address from which the original message was received Now at look at Source-Port definition in the draft, and see: TCP source port from which the reported connection originated Don't you think those two definitions should be aligned, as they are related? What I have in mind is: TCP source port from which the original message was received - Also, the following sentence doesn't seem quite right When present in a report, it MUST contain the TCP source port matching the "Source-IP" field in the same report, thereby describing completely the origin of the abuse incident. Looking at http://tools.ietf.org/html/rfc5965#section-3.2 as a guideline: o "Source-IP" contains an IPv4 or IPv6 address of the MTA from which the original message was received. Addresses MUST be formatted as per section 4.1.3 of [SMTP]. I'm wondering, don't you want to write something such as: When present in a report, it MUST contain the TCP source port of the MTA from which the reported connection originated (characterized by the "Source-IP" field in the same report), thereby describing completely the origin of the abuse incident.
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Summarizing an IM conversation with Murray) This appears to extend 5965 rather than update it. It would also help to more clearly point to exactly what in RFC6591 is being updated.
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection