On 29/Dec/11 05:30, Murray S. Kucherawy wrote:
>
> I believe Alessandro has some suggestions to make in addition to
> what's there if the Working Group concurs. I'll let him get that
> rolling.
Yes, and also some comments on what is already in the draft, or
missing pieces that have been discussed and agreed already but didn't
find their place in the draft.
Sections 6 and 7 are dedicated to solicited feedback. However, there
is a number of points that should be valid also for unsolicited
reports. If the order is not important, the common points could be
put in a common section. Specifically, for the sending part, Section
6, here's the points I think should be common and why:
1. End-users report to mailbox providers, they shouldn't go
searching whois databases and similar stuff. This point is
partially repeated already in Section 8, where it says that
sending criteria "might include direct complaint submissions
from MUAs". Using ARF for MUA-to-MP is not discussed.
2. Reports can be used to instruct filters.
4. "Feedback-Type: abuse" is fine for unsolicited reports too.
5. Ditto for other optional fields.
By contrast, points (3) and (6) cover solicited-specific stuff.
For the receiving part, Section 7, the points are:
2. ARF over SMTP is fine for unsolicited feedback too.
5. Optional fields may vary in unsolicited feedback too.
Note that for point (6), the actions, only Section 4.3.1 of RFC 6449
is useful as-is for unsolicited feedback. The rest of Section 4.3 of
that RFC contains (also) solicited-specific advice. Three notes:
* Neither the RFC nor the draft mention degrading the offending IP's
profile at the firewall.
* The RFC says replying to feedback is useless. For unsolicited
feedback, especially the first times it's being sent, some sort of
acknowledge may be meaningful.
* Both senders and receivers should keep a database of contacts and
annotate it regularly. The draft only mentions such operations for
the solicited case, referring to Section 4.4 of the RFC --point (3).
For Section 8, unsolicited complaints, the second paragraph needs to
clarify that "Senders" means "mailbox providers who are forwarding
their users' complaints". We are not stopping end-users from
reporting to whoever they like, e.g. SpamCop, are we?
This WG already agreed that ARF messages are automated and the
human-readable part is boilerplate. Conversely, technical data for an
abuse team has to be sent in non-ARF messages unless it can fit into
the provided ARF fields. This concept needs to be stated, though.
The beginning of the third paragraph of Section 8 can be changed so as
to read like so:
Recipients of unsolicited ARF reports SHOULD, in general, handle them
the same way as any other abuse reports. However, they can take
advantage of the ARF format to automate processing. Lacking [etc.]
The converse can be put in the beginning of the last paragraph of
Section 8, e.g. like so:
Published abuse-mailbox addresses SHOULD NOT reject non-ARF
messages, because producing ARF messages may occasionally be
unavailable or not-applicable. Nevertheless some large messaging
service providers specifically request that [etc.]
Finally, I propose to add the following paragraphs to the Security
Considerations section:
Mailbox Providers SHOULD perform any possible checks to ascertain
that the messages reported by their users, that they are about to
report in turn, really originated at the domain they intend to
forward it to. This includes checking that the reporting user did
not inadvertently or maliciously alter the reported message. Mailbox
Providers MAY digitally sign received messages on delivery in order
to perform this check.
Mailbox Providers SHOULD manually inspect the messages reported by
their users if their spam score is noticeably low --which might
indicate that the user hit the spam-button by mistake.
Mailbox Providers should evaluate the trustworthiness of the target
abuse team, possibly using external reputation providers. It is not
worth to send any information to domains that exist for the sole
purpose of spamming. Mailbox Providers MAY redact the reported
message, according to its policy and to the reputation of the
destination. Redacting techniques are discussed in [REDACT].
The obvious correction for an acknowledged policy contravention is to
remove the email address of the original recipient from whatever
storage it was retrieved from for sending the reported message,
including mailing lists. An abuse team may need to investigate
whether email addresses are stored legitimately on their customer's
systems, or if any malware is running there.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
