[acm-tf] Functionality

Hi all,

On 08/May/11 17:50, Peter Koch wrote:
> On Sun, May 08, 2011 at 03:50:34PM +0200, Tobias Knecht wrote:
> 
>> I feel very comfotable about the name abuse-c, because everybody
>> understands that "c" means contact as it does in admin-c and tech-c
>> already. Publishers and Users.
> 
> maybe, but we need to keep in mind that there are different types of
> users.  And there's also the subtle difference between "abuse"
> and "anti-abuse", really.

hm... "anti-abuse-c", "abuse-reports", "send-spam-complaints-here"?

Somewhere we should say that end users are supposed to report abuse to
their mailbox providers who, in turn, will lookup this addresses after
any local processing.


Please help me with terminology.  Here I call "end users" the
customers of a mailbox provider, and "users" the customers of a
network provider, who may be mailbox providers in turn.  Does that
sound correct?

>>>> - hierarchical design.
>>> 
>>> Needs clarification: does it mean the querying mechanism should be
>>> able to locate the closest covering reference for inetnum and
>>> inet6num objects?
>> 
>> That has to be discussed as well.
> 
> So, could we start the discussion?

There is a point here, whether it is the intention of the user to run
an SMTP server, or other "push" protocol, using these IP addresses.
RIPE is not interested in this information, but network providers
should be.

If users run SMTP
  * they should have an abuse-c,
  * the real name of the "owner" should be given in admin-c, and
  * they should be at a higher priority for getting IPv4 ranges.

The IPv4 priority derives from the fact that DNSBLs don't work for
IPv6.  Some operators might decide to reject mail from IPv6 addresses
until a safe filtering system is devised.  We currently have SPF and
DKIM to authenticate an IP address, but domain reputation is just
dawning.  Thus new operators without IPv4 addresses might be forced to
outsource their mail service.

If users do _not_ run SMTP
  * they should filter outbound port 25 connections, or
  * they should ask their network provider to filter that for them.

Connections can be shut down by courts in response to abuse.  In this
respect, having an abuse-c offers an occasion to mitigate abuse and
continue operations.  A network provider may want to monitor the
stream of abuse reports, possibly by replacing the abuse-report
address with a monitor-and-forward mailbox.

IMHO, a mailbox provider should come to know if one of its end users
spams.  Some mailbox providers can personally reach their end users.
They should educate their end users.  A complainant should turn to the
upstream network provider --or to an authority-- only after collecting
evidence that the appointed abuse-c doesn't sort any effect (e.g.
persistent spam from the same stream, abuse notifications
notwithstanding.)

The idea of a hierarchy comes from considering that if neither the
network provider can solve the issue, it can be considered to be a
party to the spammer.  Then a complainant may want to turn to an even
upper provider, and so forth.

>>>> - mandatory or not mandatory object

If a user is not willing to cooperate, its network provider should be
ordered to shut down the contract, in case of abuse.  Not having an
abuse-report address is going to qualify a user as an ignorant
spammer, and this may lead to kick them off the net more quickly than
if they had a syntactically correct but non-working abuse-c.

>>>> - contains e-mail and abuse-mailbox attribute
>>> 
>>> What would the difference be?
>> 
>> e-mail attribute: personal correspondence between abuse departments.
>> abuse-mailbox attribute: only automatic complaint handling.
> 
> How would one qualify as an "abuse department", allowing for inter-abuse
> communication?  Also, "automatic complaint handling" might set the limits
> for what to expect, but would be need to defined in detail, including
> formats and the like.  I think we agreed further down this email that
> splitting the contacts is the best avenue into confusion, so i'm not
> convinced here.

Neither am I.  IRT and tech-c already exist, and the team's web page
may provide further contacts.

I propose three more attributes for abuse-c, in addition to the email
address and the abuse team's URL:

1. *Domain name*

That would be the principal domain name.  Semantically, there should
be a list of domain names, in order to provide for virtual hosts, but
I'm not sure whether it's possible, and doubt it'd be very useful.

The purpose of the domain name is to provide a link to the reputation.
While negative reputation is traditionally linked to IP addresses,
positive reputation is better managed by looking at domain names.
Providing a domain name here is more reliable than looking at the
domain part of an email address in *-c entries, especially if the
corresponding role is outsourced.

For accuracy, the name listed here must have a primary MX in the DNS,
that resolves to an IP address within this same inetnum.

2. *Country code*

For legal concerns.  I'm not sure whether it would always be the same
as the inetnum's "country".

3. *Format*

Unless we stick to RFC 5965, which AFAIK is the only IETF standard
defined for this purpose, it is handy for a software tool to know how
to format messages destined to a given abuse-c.


jm2c