From owner-db-wg@ripe.net Fri Oct 18 08:19:02 1996
In my opinion notifications should *not* be sent to the originator of the change request. We had too many complaints about too many notifications. Those wishing to receive notifications of their own changes can easily achieve that by putting an alias mailbox into their notification attributes.
I think I have no problem with the above (I mean I will not argue in favour of changing this).
Note also that this smartness quite consciously introduces less 'security' because it allows someone to make clandestine changes by forging his From:-address to avoid notification. We did this because those with really high security requirements shoud use maintainers with a stronger authentication menthod.
Correct. However I originally noticed that this "feature" also works by adding a Reply-to: in the header... My point at the RIPE meeting was that when sending an update with a Reply-to, the mnt-nfy DOES get a "warning" message, that somebody made SOME updates, (since the "Congratulations" are sent to her), but has no clue wrt. WHAT exactly has been modified (usually the Subject: line does not provide accurate information - if at all)... (Of course, the situation can be even worse if the From: line is forged...) If I remember correctly, at the DB-WG session the absence of the notification (in the Reply-to case at least) was considered a *bug*. I still incline to consider the "Reply-to case" a bug (or *unwanted* feature). Forging the mail header is usually less trivial than adding a Reply-to. The latter can even occur inadvertently (this is how I discovered all the above). Janos PS. I suppose (and strongly hope :)) the authentication is based on the From: and not the Reply-to:.
Hi Janos,
Janos Zsako writes :
Note also that this smartness quite consciously introduces less 'security' because it allows someone to make clandestine changes by forging his From:-address to avoid notification. We did this because those with really high security requirements shoud use maintainers with a stronger authentication menthod.
Correct. However I originally noticed that this "feature" also works by adding a Reply-to: in the header...
The feature only disallows sending an ACK & notify message to the same E-mail address. You will always get at least an ACK message. The ACK message is sent to the Reply-To: address or the From: address if no Reply-To: address is present. The notify: message is send to all people listed except for the people that already got an ACK message.
My point at the RIPE meeting was that when sending an update with a Reply-to, the mnt-nfy DOES get a "warning" message, that somebody made SOME updates, (since the "Congratulations" are sent to her), but has no clue wrt. WHAT exactly has been modified (usually the Subject: line does not provide accurate information - if at all)...
This is true. You will receive less information then with a notification message in this case. This is clearly a disadvantage, but also an advantage for those people that are getting a bit tired of the amount of mails coming from the RIPE database automatic department.
(Of course, the situation can be even worse if the From: line is forged...)
But you will always get at least one message from the database whether it is an ACK message or a notify message. The smartness only eliminates more mails sent to one and the same E-mail address. And again <ripe-dbm@ripe.net> is always willing to investigate with the maillogs if you suspect someting like this (in fact I *did* found a forgery once and I can assure you that the person that did it will not do it another time ...)
PS. I suppose (and strongly hope :)) the authentication is based on the From: and not the Reply-to:.
I can tell you from first hand experience (that is the code is implemented as required in the specs) that the authentication is done on the From: field and nothing else then that. David K. ---
davidk@isi.edu writes:
But you will always get at least one message from the database whether it is an ACK message or a notify message. The smartness only eliminates more mails sent to one and the same E-mail address.
I stand corrected (and I remember now that we discussed this). So the only issue is whether to put more info into the standard ack message in order to make the warning more clear. Was that ever discussed by the WG? If not we might want to do it here and/or put it on the January agenda. Daniel
participants (3)
-
Daniel Karrenberg -
davidk＠isi.edu -
zsako＠banknet.net