[Bug 666694] New: uceprotect reject my mail to gnome mailing list

["sysadmin" (bugzilla.gnome.org) <bugzilla gnome org>]

https://bugzilla.gnome.org/show_bug.cgi?id=666694
  sysadmin | Mailman | unspecified

           Summary: uceprotect reject my mail to gnome mailing list
    Classification: Infrastructure
           Product: sysadmin
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: Mailman
        AssignedTo: sysadmin-maint gnome bugs
        ReportedBy: seb sfo free fr
         QAContact: sysadmin-maint gnome bugs
     GNOME version: ---


>From time to time, my mails are rejected because my ISP smtp server is
blacklisted by uceprotect. Up to now, I have been able to avoid it by using a
different server but it seems that all are blacklisted today and they will not
be removed from the list before one week.


Could you add an exception for the following IP?
212.27.42.1
212.27.42.2
212.27.42.3
212.27.42.4
212.27.42.5
212.27.42.6


Here is the reply I received:

This is the mail system at host smtp1-g21.free.fr.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<anjuta-devel-list gnome org>: host mail.gnome.org[209.132.180.169] said: 554
    5.7.1 Service unavailable; Client host [212.27.42.1] blocked using
    dnsbl-1.uceprotect.net; IP 212.27.42.1 is UCEPROTECT-Level 1 listed. See
    http://www.uceprotect.net/rblcheck.php?ipr=212.27.42.1 (in reply to RCPT TO
    command)



Reporting-MTA: dns; smtp1-g21.free.fr
X-Postfix-Queue-ID: D8CEA940629
X-Postfix-Sender: rfc822; seb sfo free fr
Arrival-Date: Wed, 21 Dec 2011 22:26:41 +0100 (CET)

Final-Recipient: rfc822; anjuta-devel-list gnome org
Original-Recipient: rfc822;anjuta-devel-list gnome org
Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.gnome.org
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host [212.27.42.1]
    blocked using dnsbl-1.uceprotect.net; IP 212.27.42.1 is UCEPROTECT-Level 1
    listed. See http://www.uceprotect.net/rblcheck.php?ipr=212.27.42.1


Partie 1.2
Sujet:
Re: [anjuta-devel] Change project property interface
De :
Sébastien Granjoux <seb sfo free fr>
Date :
Wed, 21 Dec 2011 22:26:40 +0100
Copie à :
anjuta-devel-list <anjuta-devel-list gnome org>

Hi Abderrahim,


Le 21/12/2011 13:58, Abderrahim Kitouni a écrit :
> Well, it does. Functions like anjuta_project_node_insert_property_info
> clearly create the nodes added to the list, and this is the only way to
> add PropertyInfo's to a node (if we remove the gobject property).

Yes, I don't use this function. I'm setting directly the properties_list
member. I have added it for you. I think it would be better to set the whole
properties info list in one call allowing you to reuse the same list for
several nodes.


When loading nodes, I could have temporary properties which could have
temporary PropertiesInfo structure. It's the case when the properties are
declared before the target in Makefile.am. By example if you have
  test_CFLAGS = -O0
  bin_PROGRAMS = test

A dummy CFLAGS property is added to a dummy node until we find the target node
test. These dummy properties have a temporary property info which is free with
the dummy node. To make the distinction, I have added a flag
ANJUTA_PROJECT_PROPERTY_STATIC which is cleared for such property.


> This could be done in a generic manner by using the user_data field, but
> I think it should be possible to keep the current C plugins unchanged.

Even if you use the user_data field, you need to have a function to free the
data correctly.


> The problem is that the list is a field in AnjutaProjectNode, and as
> such needs to be freed from there. And while things like you propose are
> doable in Vala (we need however to tweak generated bindings), it is
> impossible to do for dynamic languages.

To be clear, even if I'm discussing quite a lot, I would like to make it work
with dynamic languages and without too much tricky things in Vala.


> Try to think in Python: the info list is a Python list, and in order to
> get this list to the node object (even through a possible
> set_properties_info) it needs to be converted to a GList, then either
> its ownership is taken by the node object, or it is freed just
> afterwards. So the node object needs to own at least the list (even
> though it doesn't need to own its contents).

How does it work if the object doesn't own the content? the content is a Python
structure by example, so it should be converted to a C structure no?

In my idea, the properties info list argument is like the gpointer data
argument of g_list_append by example.

I have looked as instrospection documentation, it has improved since last time
I read it. Indeed, the argument should be marked as transfer none but we expect
that the caller keep a valid copy of the parameter. I think it triggers issues
similar to call back which is tricky.


Anyway, I think we can make it works exactly as you want. Having both the
properties and the properties information content and list belonging to the
node. As I have explained above, it's already working like this when loading a
node.


Then, I'm still a bit annoyed that the properties info list will be duplicated
in project backend not written in C. I think one solution for this is to create
a new object which is a AnjutaPropertyInfoList. For C it could be just a GList
so it cost nothing, but for a Python backend it can be a opaque object that the
Python backend has to create, fill with needed data and pass to the project
node. So we could have functions like

AnjutaProjectPropertyInfoList *anjuta_project_property_info_list_new ();
void anjuta_project_property_info_list_free (
        AnjutaProjectPropertyInfoList *list);
void anjuta_project_property_info_list_add (
        AnjutaProjectPropertyInfoList *list,
        AnjutaProjectPropertyInfo *info);

We could have (transfer full) for the info parameter of list_add function and
(transfer none) when this list is used to initialize a new node. So it's up to
the backend to keep all property information lists with the node using them as
long as the backend is running. What do you think?

I could be a bit more complex to use (one additional object) just to gain
memory perhaps we don't care.



Regards,

Sébastien

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the QA contact of the bug.
You are watching the assignee of the bug.