-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Meijer wrote: | Hi, | | On Fri, 9 Jan 2004, Rev Adrian Kennard wrote: | | |>I am new to this mailing list, so forgive me if this has been covered |>before. |> |>It seems there is a pretty clear need for an extra field in inetnum and |>inet6num records, specifically something like an abuse-c field |>referencing a person record. |> |>A lot of inetnum records I have seen have a remarks field identifying |>the abuse ocntact, but this is in an inconsistent format making it |>difficult to automate in any way. It also seems that a lot of network |>administrators (admin-c) do not feel they should administer their |>network to remove viruses, etc, and get quite annoyed when contacted |>regarding abuse. |> |>What would be the procedure for proposing such a new field? | | | It's already there :). | | Please check | http://www.ripe.net/ripe/docs/irt-object.html | | and the TF-CSIRT effort to make it easier to use this: | http://www.dfn-cert.de/team/matho/irt-object/ | | It's not perfect but it's there. I did look at the IRT object, but it looked far far more complex than the simple requirement of "who do I email abuse to for an IP address", which is what the "remarks" fields in a lot of inetnum objects are providing. Indeed, I am somewhat concerned by the "Creation procedure" which looks overly complex and a manual process. I will however read up on irt objects in more detail and get one created. Thanks for the feedback. - -- Rev Adrian Kennard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//rWCHBb4e52L0Y0RAu+rAKCMUG2qBtxZvZTIxmomdaWzrprB2QCaAuwI zLr4T5mCGF6stm/KbpgFgtY= =Rc3P -----END PGP SIGNATURE-----

Hi, I wasn't aware this object type existed, but I can see ripe-254 is from July 2002, so its not exactly new.. The current situation in my opinion is that people (or applications) simply send their abuse complaint to all possible email addresses showing up when doing a whois on an IP address. In many cases such mails are never replied, which is the reason why all addresses are used instead of just trying one, people believe there is a greater chance for a reply this way.. This behaviour will probably not change until people feel confident that a mail to an abuse address found on a whois is read by the actual technicians who takes care of this. Realistically I think the majority of inetnum objects needs to have such a record before anything will change. Therefore I believe it has to be mandatory for all new inetnum objects to reference an abuse address. This irt object seems a bit complex with encryption and so on if the intention should be for all inetnums to reference such an object. It has to be the responsibility of the LIR maintaining the address block to ensure endusers are not abusing the addresses. Only the LIR can create inetnum objects for their address block (else something is very wrong!) and this way have the ability to ensure the correct abuse address is used, so I don't see how it can be absolutely necessary to use encryption..?! The procedure for implementing the irt object (modify every single inetnum object) does not exactly motivate LIRs, what about referencing an abuse object from the maintainer object? MNT-BY is mandatory on inetnum objects, so it should be possible for a LIR to reference all inetnum objects this way by just adding an attribute to their maintainer object. I imagine it would be possible for the whois to show a part of a maintainer object? I would suggest to use something simpler than the irt object, what about a role object or simply a person object as suggested by Adrian Kennard? The most important has to be to have all inetnum objects referencing some kind of abuse object, until then it will not have much effect. Once this goal is reached it can be extended with encryption and so on if the LIRs wants it. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net

-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net]On Behalf Of Jan Meijer Sent: 9. januar 2004 13:33 To: Rev Adrian Kennard Cc: db-wg@ripe.net Subject: Re: [db-wg] abuse-c

Hi,

On Fri, 9 Jan 2004, Rev Adrian Kennard wrote:

...

I am new to this mailing list, so forgive me if this has been covered before.

It seems there is a pretty clear need for an extra field in inetnum and inet6num records, specifically something like an abuse-c field referencing a person record.

A lot of inetnum records I have seen have a remarks field identifying the abuse ocntact, but this is in an inconsistent format making it difficult to automate in any way. It also seems that a lot of network administrators (admin-c) do not feel they should administer their network to remove viruses, etc, and get quite annoyed when contacted regarding abuse.

What would be the procedure for proposing such a new field?

It's already there :).

Please check http://www.ripe.net/ripe/docs/irt-object.html

and the TF-CSIRT effort to make it easier to use this: http://www.dfn-cert.de/team/matho/irt-object/

It's not perfect but it's there.

Jan

-- /~\ The ASCII / Jan Meijer \ / Ribbon Campaign -- -- SURFnet bv X Against HTML / http://www.surfnet.nl/organisatie/jm/ / \ Email http://cert-nl.surfnet.nl/

On Fri, Jan 09, 2004 at 01:32:39PM +0100, Jan Meijer wrote:

...

It seems there is a pretty clear need for an extra field in inetnum and inet6num records, specifically something like an abuse-c field referencing a person record.

It's already there :).

Please check http://www.ripe.net/ripe/docs/irt-object.html

and the TF-CSIRT effort to make it easier to use this: http://www.dfn-cert.de/team/matho/irt-object/

It's not perfect but it's there.

That's exactly the point, IRT is there but far for perfect for the purpose the original poster is refering to. The problem is that there are a lot of 'tools' out there who have a mechansim to query ripe or another db for the inetnum and all person and role objects asociated with it to find line which contains an '@' to be a valid address to complain to. Refering to an abuse address in remarks is possible, but then even you have to be carefull to not enclose the address in <> as some webbased tools strip them out. Not to judge on all, but I get the feeling that there are a lot of people who don't know what the fields mean, let alone they will know on how to use the irt object. So we can start advertising the irt mechanism to both the LIR's and the people who migth come searching for an address to send a complaint to. I don't think it is very likely to hit a large public in a reasonable time. Introducing an extra (mandatory) field in inetnum objects to hold the abuse address for that specific netblock and nothing more makes it much more easier for all those people who write automated process to get the information requested and not have to fallback to listing addresses in changed: fields as a possible way to complain. Introducing it and making some noise about it on certain mailinglists and fora, will probably be picked much faster. As such can this subject be put an the wg-agenda for ripe-47 ? To formalize it a little bit I wan't to put forward the proposal to add an 'abuse' field to inetnum and inet6num objects. This field will be limited to one line containing a syntactically correct email address which can be used to send abuse complaints on ip-addresses in that block. Reasons to do so are to give people an easy way to automate finding a place to complain and giving LIR's an easy and generic way to publish the abuse address, without having to resort to the unknown and for the average database user complex method of the irt-object. As a side effect this might result in more spammers hitting the abuse box directly as they harvest the database :) I'm not stating that this is the best way, but a have a feeling this can improve things a lot. Grtx, Marco Hogewoning

MarcoH wrote:

On Fri, Jan 09, 2004 at 01:32:39PM +0100, Jan Meijer wrote:

...

...

It seems there is a pretty clear need for an extra field in inetnum and inet6num records, specifically something like an abuse-c field referencing a person record.

It's already there :).

Please check http://www.ripe.net/ripe/docs/irt-object.html

and the TF-CSIRT effort to make it easier to use this: http://www.dfn-cert.de/team/matho/irt-object/

It's not perfect but it's there.

That's exactly the point, IRT is there but far for perfect for the purpose the original poster is refering to.

The problem is that there are a lot of 'tools' out there who have a mechansim to query ripe or another db for the inetnum and all person and role objects asociated with it to find line which contains an '@' to be a valid address to complain to.

Well, except that the word 'abuse' may be a bit easier to understand than 'irt' for many non-RIPE-database-gurus, I do not see much difference between a reference to an IRT object or a reference to a person/role object. The big difference is that an IRT is usually better protected (see below) and provides more information. The protection that the IRT gives over a person/role object includes: - It MUST be maintained, while a person or role object does not have to be; it can be completely unprotected. - Authorization from the IRT is required, before the IRT can be linked to the inet[6]num object. This is important so not all mail for a malicious company can go to another (or non-existent) address. Moreover, if the IRT object is maintained by TRUSTED-INTRODUCER-MNT (or possibly other organisations of Incident Response Teams), it means the object's information has been verified and is verified on a regular basis.

Refering to an abuse address in remarks is possible, but then even you have to be carefull to not enclose the address in <> as some webbased tools strip them out.

Not to judge on all, but I get the feeling that there are a lot of people who don't know what the fields mean, let alone they will know on how to use the irt object.

The encryption information in the IRT object is just for communication that needs encryption. For normal abuse reports just the e-mail/phone/fax/address fields will suffice.

So we can start advertising the irt mechanism to both the LIR's and the people who migth come searching for an address to send a complaint to. I don't think it is very likely to hit a large public in a reasonable time.

Neither would another extra attribute, because people will still be sending their mail to ALL adresses found...

Introducing an extra (mandatory) field in inetnum objects to hold the abuse address for that specific netblock and nothing more makes it much more easier for all those people who write automated process to get the information requested and not have to fallback to listing addresses in changed: fields as a possible way to complain.

If they can find the information in a person/role object, so can they in an IRT object. If the tool finds an mnt-irt attribute, just let it look for the contact information (address, phone, fax-no and e-mail) in the IRT object and display that to the user.

Introducing it and making some noise about it on certain mailinglists and fora, will probably be picked much faster.

I agree on that point...

As such can this subject be put an the wg-agenda for ripe-47 ?

To formalize it a little bit I wan't to put forward the proposal to add an 'abuse' field to inetnum and inet6num objects.

This field will be limited to one line containing a syntactically correct email address which can be used to send abuse complaints on ip-addresses in that block.

Reasons to do so are to give people an easy way to automate finding a place to complain and giving LIR's an easy and generic way to publish the abuse address, without having to resort to the unknown and for the average database user complex method of the irt-object.

I agree that making an IRT object is a bit more difficult than making an extra attribute, but reading an IRT object is not so difficult and could be easily automated.

As a side effect this might result in more spammers hitting the abuse box directly as they harvest the database :)

As if the abuse boxes aren't full enough already... ;-) Personally, I would suggest promoting the current advanced mechanism instead of inventing something new. Regards, Menno Pieters -- Menno Pieters - Stelvio Postbus 215, 3740 AE Baarn phone: +31-35-5.429.324 / fax: +31-35-5.429.327 XOIP: +31-84-8.720.349 / Web: http://www.stelvio.nl/

Hi Menno,

Well, except that the word 'abuse' may be a bit easier to understand than 'irt' for many non-RIPE-database-gurus, I do not see much difference between a reference to an IRT object or a reference to a person/role object. The big difference is that an IRT is usually better protected (see below) and provides more information.

The protection that the IRT gives over a person/role object includes: - It MUST be maintained, while a person or role object does not have to be; it can be completely unprotected. - Authorization from the IRT is required, before the IRT can be linked to the inet[6]num object. This is important so not all mail for a malicious company can go to another (or non-existent) address.

Moreover, if the IRT object is maintained by TRUSTED-INTRODUCER-MNT (or possibly other organisations of Incident Response Teams), it means the object's information has been verified and is verified on a regular basis.

We can agree that it would be preferable to have a special abuse-object with a mandatory maintainer attribute instead of just refering a role/person object, still the most important is that the whois database is an effectiv tool to locate an abuse address. Regarding authorization of the object, it could be done kind of the same way as a route object meaning maintainer has to be the same or can authorize the other. The LIR maintaing an address block is responsible for taking care of the related abuse cases. I see no problem in some LIRs outsourcing this to a third party (which I guess is what you mean by "other organisations of Incident Response Teams"), but I don't see it to be more trustworthy if a third party is involved than if the LIR takes care of it. But I do see it as a problem if such third party needs to be verified and such procedure makes this matter so complicated that almost no LIRs bother using it (as the case is today).

...

So we can start advertising the irt mechanism to both the LIR's and the people who migth come searching for an address to send a complaint to. I don't think it is very likely to hit a large public in a reasonable time.

Neither would another extra attribute, because people will still be sending their mail to ALL adresses found...

The current problem is that the majority of LIRs have chosen not to use irt, probably both because it haven't been announced enough and because it is too complicated. As soon as an attribute is implemented in most inetnum objects, meaning people have a reason to trust that an abuse address actually works, then people will stop using any other address, simply because the abuse address will work and the others will not.

...

Introducing an extra (mandatory) field in inetnum objects to hold the abuse address for that specific netblock and nothing more makes it much more easier for all those people who write automated process to get the information requested and not have to fallback to listing addresses in changed: fields as a possible way to complain.

If they can find the information in a person/role object, so can they in an IRT object. If the tool finds an mnt-irt attribute, just let it look for the contact information (address, phone, fax-no and e-mail) in the IRT object and display that to the user.

Yes, but thats not the point. Either the current irt object or a new and simpler abuse object implemented in most inetnum objects will be easy to retrieve abuse addresses from. The point is simply that it is much more realistic to implement a simple object than a complex one in most inetnum objects.

...

As such can this subject be put an the wg-agenda for ripe-47 ?

To formalize it a little bit I wan't to put forward the proposal to add an 'abuse' field to inetnum and inet6num objects.

Sounds like a good idea.

Personally, I would suggest promoting the current advanced mechanism instead of inventing something new.

The question simply is if ALL LIRs are ready/willing to implement the current irt object, its much more likely that the majority will implement a simpler version. The irt features can then be introduced at a later time once all inetnum objects have been updated. I would suggest a project be initiated like when encryption was made mandatory in maintainer objects. Abuse addresses in inetnum objects will not have much effect until they are implemented in all inet[6]num objects. Once the correct attribute has been decided it must be implemented ASAP. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net

Menno Pieters (Stelvio) wrote:

The object itself is not so complicated. The mechanism to create it is, and that has a purpose (see above).

I can't see anything "above" which explains why the creation purpose should be complicated. Can you elaborate? Thanks John JANET-CERT

Menno Pieters (Stelvio) wrote:

To elaborate on that, the complications for creating an IRT object are: - You need a maintainer for an IRT object (which is not required for an extra attribute or a person/role object); - Strong authentication from both the IRT and the LIR is required to link an IRT object to the inet[6]num object.

The reasons to do it this way is to prevent that the IRT mentioned in the IRT object gets complaints about abuse made form IP ranges that they are not responsible for, simply because "Evil Company" put the e-mail address of the IRT in its inet[6]num object (or as Daniel Karrenberg suggested in on of the maintainer objects protecting the object).

So both the IRT and the LIR (even if they are in the same room or just next door), must agree. In a small organisation it is possible that it's the same (group of) person(s), using the same PGP key and the problem is void, because the request needs to be signed only once.

I have never understood what this gives you. If "Evil Company" wants to misdirect abuse reports (why?) they can circumvent this by making a fake IRT object with IRT XYZ as the contact email address. John Green JANET-CERT

Marco d'Itri wrote:

On Jan 12, John Green <j.green@ukerna.ac.uk> wrote:

...

I can't see anything "above" which explains why the creation purpose should be complicated. It's complicated if you want to use TI. When I wanted to create an IRT object I just asked RIPE to authorize it, and it was done quickly and with no pain. Currently I see no reason to use TI.

TI is an organisation that verifies the information, so that it can be *trusted*. For ordinary users it may be to hard to understand this and how to make sure it all correct. For IRT among eachother it may be important.

BTW, what about returning the IRT record by default for inetnum queries? This would let more people know about it and if decorated with big ASCII art could partially solve the problem of lusers writing to every email address they find in the answer.

Well, *that* is a good idea! Regards, Menno Pieters -- Menno Pieters - Stelvio Postbus 215, 3740 AE Baarn phone: +31-35-5.429.324 / fax: +31-35-5.429.327 XOIP: +31-84-8.720.349 / Web: http://www.stelvio.nl/

Hi Menno, Thank you for your comments.

...

The LIR maintaing an address block is responsible for taking care of the related abuse cases. I see no problem in some LIRs outsourcing this to a third party (which I guess is what you mean by "other organisations of Incident Response Teams"), but I don't see it to be more trustworthy if a third party is involved than if the LIR takes care of it. But I do see it as a problem if such third party needs to be verified and such procedure makes this matter so complicated that almost no LIRs bother using it (as the case is today).

In the current implementation the IRT and the LIR (maintainer) are supposes to be different groups of persons, whether they are part of the same organisation of not.

This is where I disagree with the idea behind the irt implementation, I do not see the reason for making the distinction between LIR and IRT as it do not apply to all LIRs. In many LIRs abuse is handled by the same group (and sometimes even the same persons) as the ones handling general LIR functions.

for its IP range, but the IRT has to authorise this, by counter-signing the request to add an mnt-irt attribute to the inet[6]num object. Otherwise any maintainer of an inet[6]num (which could be delegated) could simply make the inet[6]num object point to any IRT for abuse complaints. The current mechanism is to protect the IRT form being blamed for things they are not responsible for simply because "Evil Company" points a finger towards them.

I very much agree with you that a LIR shall not be able to "forward the problem" by using another organsations irt object without permission. But the question is how many LIRs choose to "outsource" abuse, even to a group within the organization? I could have hoped this had been determined before implementing the IRT object. I understand that it is necessary for LIRs who prefer to use a seperate group within the organization or a third party to use encryption for authentication, but can we agree that for the rest of the LIRs it could just as easily be done by maintainer authentication like when creating route objects? If so what would the disadvantage be? Im not opposed that some LIRs can effectively outsource abuse even if it requires special objects/attributes in the Ripe database, but Im very much opposed that these special objects/attributes are mandatory meaning it becomes an obstacle for LIRs prefering to keep abuse within the organization.

...

The current problem is that the majority of LIRs have chosen not to use irt, probably both because it haven't been announced enough and because it is too complicated. As soon as an attribute is implemented in most inetnum objects, meaning people have a reason to trust that an abuse address actually works, then people will stop using any other address, simply because the abuse address will work and the others will not.

That is exactly why there must be double authorization for the relationship between IRT and inet[6]num: to ensure correctness and mutual agreement.

Only in cases where LIRs choose to outsource abuse, if it is within the same organzation, one LIR cannot (hopefully) hijack another LIRs maintainer, meaning an abuse object created and used by one LIR cannot be used by another.

I agree that there must be a better mechanism than the comments in the inet[6]num and maintainer objects, but I'm still in favor of promoting the existing one and perhaps explaining it a little better.

The reason why a better explanation is needed for the current IRT object is because it has extensive authentication, if many LIRs have no use for these extra features, can you find any reason for them to spent time finding out how to use/create this object? Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net

This would certainly address my needs. Niall O'Reilly On 12 Jan 2004, at 07:45, Daniel Karrenberg wrote:

Realistically speaking it is not very likely that stupid tools will change very soon. Nonetheless I like the proposal of a simple 'abuse-mailbox' attribute containing an e-mail address and nothing else. This would open the possibility to ask tool-writers not to spam all the other e-mail addresses in the inet*num objects and any object remotely related to them. In other words: we provide specific information where to send such messages, so it is a Bad Idea(TM) to send it anywhere else.

MarcoH wrote:

Not to judge on all, but I get the feeling that there are a lot of people who don't know what the fields mean, let alone they will know on how to use the irt object.

For the record, there is one other way you might use to indicate an abuse contact, via the "trouble:" attribute in the role object: Contains information on who to contact when there are problems. Also, what various contact information means is not clear. What administration does the "admin-c:" do exactly? Only update the RIPE Database? Coordinate with the RIPE NCC? Is it the CEO of a company? The manager of the IT department? Or an independent contractor who handles all the details of connectivity? I know that all of these interpretations do appear in the database. A similar range of meanings are attached to the "tech-c:" attribute. On of the problems that was identified when the irt object type was defined is that there are a lot of meanings of "incident" that the "irt" could be responding to. The same applies to an "abuse-c:" attribute. Does abuse mean spam? DoS? Illegally trading movies? E-mailed viruses? Pornography? Gambling? Hijacking address space? Do you have different desks for these different types of abuses? If so, does it make sense to have different contacts for them? (History shows this doesn't matter too much - as users tend to send to every e-mail they can find. But in the future, it would make modifying output of tools to only display relevant information easier.) -- Shane Kerr RIPE NCC

On Mon, Jan 12, 2004 at 09:55:06AM +0100, Shane Kerr wrote:

On of the problems that was identified when the irt object type was defined is that there are a lot of meanings of "incident" that the "irt" could be responding to. The same applies to an "abuse-c:" attribute. Does abuse mean spam? DoS? Illegally trading movies? E-mailed viruses? Pornography? Gambling? Hijacking address space?

Do you have different desks for these different types of abuses? If so, does it make sense to have different contacts for them? (History shows this doesn't matter too much - as users tend to send to every e-mail they can find. But in the future, it would make modifying output of tools to only display relevant information easier.)

That's why I proposed a simple attribute only containing 1 single email address where people can send their complaints. It will mostly end-up being abuse@isp for every single inetnum. It's harder to maintain, but easier to delegate abuse handling for a specific inetnum to a certain part of the company or even to the enduser. If you define a abuse-c: as a person/role object, you still have the problem that people need to resolve it and then possibly get multiple addresses. So the problem doesn't get solved and we can just stick with the irt-object. I think for this we can better stick to the most simple solution available. Grtx, MarcoH

On Mon, Jan 12, 2004 at 03:39:32PM +0100, Marco d'Itri wrote:

...

If you define a abuse-c: as a person/role object, you still have the problem that people need to resolve it and then possibly get multiple addresses. So the problem doesn't get solved and we can just stick with the irt-object. Not if the relevant IRT object is automatically returned for every inetnum query. This is what ARIN does, BTW.

Ok, but in that case we need to launch a campaign to get people aware of the irt object and how they should use it.

...

I think for this we can better stick to the most simple solution available. I think you should define better you requirements of simplicity...

IMHO you can define two groups of database users: - the relatively small group of techies who are updating the database and/or know how to use it and how to find specific information like incident response teams. - The large group of users who hardly know what the database is and why it is there and only want to get one piece of information: Where can I complain about this spam I got. For the first group everything is in place and working. As from my personal experience the second group doesn't understand how things work and how to read the information returned on a query and to be more specific admin-c, tech-c and especially changed attributes are not by default the best address to send complaints to as we already mentioned in the remarks section which got returned on the same query. Reading the remarks section which is used by most people to list abuse information is easy for the human reader, although I have came accross webinterfaces who didn't like the <address> notation most people use. But it's hard for a programmer to 'read' as it is not fixed format. Introducing the abuse: attribute as a single syntactically valid[1] email address on inetnum objects or the first level of objects it refers to makes it simple in the way that: whois ip-address | grep abuse: Will always result in a valid email address to send the complaint, without the need to walk to a tree of objects referring to each other and search for remarks fields pointing to the abuse desk or just collecting everything which includes an '@' and not even using uniq on them. Take it from the point of the non-professional "I'm sure this is easy to write in perl/php/shell/cobol/whatever" programmer who needs to query and parse the ripe database. MarcoH

On Jan 12, MarcoH <marcoh@marcoh.net> wrote:

...

...

If you define a abuse-c: as a person/role object, you still have the problem that people need to resolve it and then possibly get multiple addresses. So the problem doesn't get solved and we can just stick with the irt-object. Not if the relevant IRT object is automatically returned for every inetnum query. This is what ARIN does, BTW. Ok, but in that case we need to launch a campaign to get people aware of the irt object and how they should use it. The same would apply to abuse-c as well. I think IRT has the advantage that it already exists. If the server could be changed to return by default the relevant IRT object for inetnum queries I think it would be at least as useful as the half-proposed abuse-c attribute.

Introducing the abuse: attribute as a single syntactically valid[1] email address on inetnum objects or the first level of objects it refers to makes it simple in the way that:

whois ip-address | grep abuse: IRT would be about as easy to use if returned by default. Some ASCII banner would help pointing lusers at the right address where to send complaints. Do not forget that abuse-c would have to refer to a role or person address (just using a mailbox as the attribute content would be really too much ugly IMO, and not consistent with the general style of the DB), so a little indirection would still be present.

Will always result in a valid email address to send the complaint, without the need to walk to a tree of objects referring to each other and search for remarks fields pointing to the abuse desk or just collecting everything which includes an '@' and not even using uniq on them. You will always find a better idiot... But procmail can help you.

-- ciao, | Marco | [4069 coxDCUA1EuKYs]