This makes no difference toward the adoption of a proposed methodology. I.e.
all vendors do not implement every RFC which is recommended for an IP host,
however this does not affect interoperability. Likewise, citing or 'adoption'
of RFC2142 concepts or the RFC itself, in an anti-spam architecture is not
limiting to the scope or effectiveness of that architecture. Whether one or
many methods are supported for determination of abuse reporting, I think, will
be implementation specific and should be left as such.
Adoption of such a 'standard' into the technical specifications of a working
solution should appropriately reference such RFCs for the sake of a common
point of reference. For example, not everyone uses
abuse(_at_)somedomain(_dot_)tld,
however the idea of an address for reporting this class of 'incident' is a
widely supported concept though not a requirement. If an implementation uses
some specific methodology that method should be described and/or its
assumptions enumerated, e.g. "this software...uses RFC2142 recommended e-mail
addresses for determination of inappropriate use reporting."
-e
On Wednesday, January 07, 2004 8:02 PM, Markus Stumpf
[SMTP:maex-lists-spam-ietf-asrg(_at_)Space(_dot_)Net] wrote:
On Wed, Jan 07, 2004 at 12:02:51PM +0000, Jon Kyme wrote:
I think "abuse" is pretty much the de facto standard, supported by rfc2142,
adopting anything else would take some justifying.
Yes, but abuse @ whatdomain?
The most reliable information is the IP address from which the spam
was injected into my system.
------------------------------------------------------------------------
h68-146-73-40.cg.shawcable.net:68.146.73.40 rbl-allowed:
<rosadovs(_at_)9online(_dot_)fr> to <promote(_at_)space(_dot_)net>
Looking up 68.146.73.40 with whois.arin.net is fine:
OrgAbuseEmail: internet(_dot_)abuse(_at_)sjrb(_dot_)ca
------------------------------------------------------------------------
Let's try another one:
------------------------------------------------------------------------
customer-hmo-61-203.megared.net.mx:200.77.61.203 rejected:
<btkd2mr(_at_)coastalnet(_dot_)com> to <cosmiccard(_at_)space(_dot_)net>
badrcptto
Comment: This IP address range is under LACNIC responsibility for further
Comment: allocations to users in LACNIC region.
Comment: Please see http://www.lacnic.net/ for further details, or check
the
Comment: WHOIS server located at whois.lacnic.net
At least there is
ReferralServer: whois://whois.lacnic.net
$ whois -h whois.lacnic.net 200.77.61.203
and now?
------------------------------------------------------------------------
The LACNIC example also holds for e.g. RIPE and leads to things like:
remarks: ---------------------------------------------------------
remarks: Please send abuse and spam notifications to abuse(_at_)inet(_dot_)fi
remarks: ---------------------------------------------------------
trouble: SPAM/COMPLAINTS to: de-fp-btignite-abuse(_at_)bt(_dot_)com
trouble: SPAM/COMPLAINTS to other addresses will probably be ignored.
remarks: ************************************************************
remarks: * ABUSE CONTACT: abuse(_at_)t-ipnet(_dot_)de IN CASE OF HACK
ATTACKS, *
remarks: * ILLEGAL ACTIVITY, VIOLATION, SCANS, PROBES, SPAM, ETC. *
remarks: ************************************************************
remarks: Please send abuse notification to abuse(_at_)telecomitalia(_dot_)it
(I think you get the idea) while other have no abuse contact at all.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg