From this message:
https://mailarchive.ietf.org/arch/msg/last-call/nGTxTOuWr3ngCsOniPTjsFvZeoM
I propose a slight modification to the standard to allow organizations to specify an abuse contact. The goal is to provide a separate form of contact for cases where the organization is suspected of originating some security incident or abusive activity, rather than being a potential victim.
Insert and renumber:
3.5.4. Abuse Contact
This directive indicates an address that incident responders should use for
reporting security incidents or abuse. The value MAY be an email
address, a phone number and/or a web page with contact information.
The "Abuse:" directive MAY be present in a security.txt
file. If this directive indicates a web URL, then it MUST begin with
"https://" (as per section 2.7.2 of [RFC7230]). Security email
addresses SHOULD use the conventions defined in section 4 of
[RFC2142].
The value MUST follow the URI syntax described in [RFC3986]. This
means that "mailto" and "tel" URI schemes MUST be used when
specifying email addresses and telephone numbers, as defined in
[RFC6068] and [RFC3966]. When the value of this directive is an
email address, it is RECOMMENDED that encryption be used (as per
Section 3.5.4).
If this directive is missing, then incident responders MAY report security
incidents or abuse according to the "Contact:" directive.
The precedence SHOULD be in listed order. The first field is the
preferred method of contact. In the example below, the email address
is the preferred method of contact.
Abuse: mailto:security@example.com
Abuse: tel:+1-201-555-0123
Abuse: https://example.com/security-contact.html
Additionally, in section 5, insert in to the ABNF, the appropriate definitions for the new abuse-field token
field = ack-field /
contact-field /
abuse-field /
encryption-field /
hiring-field /
policy-field /
ext-field
abuse-field = "Abuse" fs SP uri
Additionally, in section 6, include a stanza for the new "Abuse:" field:
Field Name: Abuse
Description: contact information to use for reporting security incidents or abuse
Multiple Appearances: Yes
Published in: this document
Status: current
Change controller: IESG
From this message:
https://mailarchive.ietf.org/arch/msg/last-call/nGTxTOuWr3ngCsOniPTjsFvZeoM