You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
From this message:
https://mailarchive.ietf.org/arch/msg/last-call/nGTxTOuWr3ngCsOniPTjsFvZeoM
The text was updated successfully, but these errors were encountered: