Pierre-Luc Boucheron | 11 Oct 2011 10:34
Picon
Picon
Favicon

Unable to "Customizing Address Book Search Capability in Convergence 2" ...

Hello,

Running Convergence 2-1.01, I'm trying to setup this following
customization "Customization Example - Customizing Address Book Search
Capability in Convergence 2" as described on
http://wikis.sun.com/display/CommSuite/Customizing+Address+Book+Search+Capability+in+Convergence+2
but it's not working.

Here's my partial setup:

#
/opt/SUNWappserver/domains/domain1/docroot/iwc_static/c11n/allDomain/js
> diff customize.js customize.js.6
88,101d87
< dojo.provide("c11n.allDomain.js.widget.addressBook.QuickSearchForm");
< dojo["require"]("iwc.widget.addressBook.QuickSearchForm");
< dojo.declare("iwc.widget.addressBook.QuickSearchForm",
iwc.widget.addressBook.QuickSearchForm, {
<         postMixInProperties: function() {
<                 this.inherited(arguments);
<
<                 // "defaultSearch" attr can be one of the followings:
<                 // "entry/displayname,email", "entry/displayname",
"email",
<                 // "person/surname", "person/givenname", "phone"
<                 //this.attr("defaultSearch", "phone");
<                 this.attr("defaultSearch", "person/surname");
<         }
<
< });
(Continue reading)

Narasimha Reddy Dwarsala | 11 Oct 2011 11:25
Picon
Favicon

Re: Unable to "Customizing Address Book Search Capability in Convergence 2" ...

On 10/11/11 14:04, Pierre-Luc Boucheron wrote:
> Hello,
>
> Running Convergence 2-1.01,
This will work from Convergence 2-2.01 (2 patch2) onwards.
>  I'm trying to setup this following
> customization "Customization Example - Customizing Address Book Search
> Capability in Convergence 2" as described on
> http://wikis.sun.com/display/CommSuite/Customizing+Address+Book+Search+Capability+in+Convergence+2
> but it's not working.
>
> Here's my partial setup:
>
> #
> /opt/SUNWappserver/domains/domain1/docroot/iwc_static/c11n/allDomain/js
>   
>> diff customize.js customize.js.6
>>     
> 88,101d87
> < dojo.provide("c11n.allDomain.js.widget.addressBook.QuickSearchForm");
> < dojo["require"]("iwc.widget.addressBook.QuickSearchForm");
> < dojo.declare("iwc.widget.addressBook.QuickSearchForm",
> iwc.widget.addressBook.QuickSearchForm, {
> <         postMixInProperties: function() {
> <                 this.inherited(arguments);
> <
> <                 // "defaultSearch" attr can be one of the followings:
> <                 // "entry/displayname,email", "entry/displayname",
> "email",
> <                 // "person/surname", "person/givenname", "phone"
(Continue reading)

Jean-Luc Marrion | 13 Oct 2011 13:47
Picon
Favicon

Calendar message

Hi,

I am looking  for an explanation of  this message. It is  logged in the 
log of Calendar Server version 6.3-24.01 (http.log)

cshttpd(4319)  General Notice: Process has refused connections 2049 times

Best regards

--

-- 
Jean-Luc Marrion

Marko Jauhiainen | 13 Oct 2011 14:44
Picon
Picon

mgrpBroadcasterPolicy(?) puzzle

Hi,

[Running Oracle Communications Messaging Exchange Server 7u4-21.01 64bit 
(built Feb 16 2011)
libimta.so 7u4-21.01 64bit (built 19:04:33, Feb 16 2011)]

More than a year ago I set up some for-testing-only mailing lists that 
required the sender to be authenticated before s/he could send mail to 
the list. Judging by my notes and the documentation I produced at the 
time, I got everything working more or less just as I expected.

Now I tried to start using these kind of lists in our production 
environment but they no longer seem to work the way they worked when I 
last tested them. I am sure the fault is all mine but since I cannot 
spot the (obvious?) problem, I wonder if you could help me out a bit here.

Here is a sample LDAP-entry for a mailing list.

mgrpMsgRejectText: You need authentication to use this list.
mgrpBroadcasterPolicy: AUTH_REQ
cn: Test
objectClass: top
objectClass: groupOfUniqueNames
objectClass: nsManagedMailList
objectClass: inetMailGroup
objectClass: inetLocalMailRecipient
objectClass: inetMailGroupManagement
mgmanJoinability: none
description: Test mailing list
mgrpRFC822MailMember: user1@...
(Continue reading)

Ned Freed | 13 Oct 2011 18:29

Re: mgrpBroadcasterPolicy(?) puzzle

> Hi,

> [Running Oracle Communications Messaging Exchange Server 7u4-21.01 64bit
> (built Feb 16 2011)
> libimta.so 7u4-21.01 64bit (built 19:04:33, Feb 16 2011)]

> More than a year ago I set up some for-testing-only mailing lists that
> required the sender to be authenticated before s/he could send mail to
> the list. Judging by my notes and the documentation I produced at the
> time, I got everything working more or less just as I expected.

> Now I tried to start using these kind of lists in our production
> environment but they no longer seem to work the way they worked when I
> last tested them. I am sure the fault is all mine but since I cannot
> spot the (obvious?) problem, I wonder if you could help me out a bit here.

> Here is a sample LDAP-entry for a mailing list.

> mgrpMsgRejectText: You need authentication to use this list.
> mgrpBroadcasterPolicy: AUTH_REQ
> cn: Test
> objectClass: top
> objectClass: groupOfUniqueNames
> objectClass: nsManagedMailList
> objectClass: inetMailGroup
> objectClass: inetLocalMailRecipient
> objectClass: inetMailGroupManagement
> mgmanJoinability: none
> description: Test mailing list
> mgrpRFC822MailMember: user1@...
(Continue reading)

Derek Diget | 13 Oct 2011 19:02
Favicon

BANNER_PURGE_DELAY logging question/RFE


7u4-22.01 64bit on Solaris SPARC

See option.dat setting at the end of message.

Have been playing around with setting BANNER_PURGE_DELAY in tcp_local 
(to 100).  I was wondering if there is a RFE open to log information 
related to that setting?

In the X record I am seeing

 	X TCP|aaa.bbb.ccc.ddd|25|www.xxx.yyy.zzz|8447 SMTP Error reading SMTP packet 1

I know the X record already means the connection was rejected, but 
"reading SMTP packet 1" doesn't mean a whole lot to me right way.
Would be nice if it said something like:

 	X TCP|aaa.bbb.ccc.ddd|25|www.xxx.yyy.zzz|8447 Client talked before banner was given
or
 	X TCP|aaa.bbb.ccc.ddd|25|www.xxx.yyy.zzz|8447 BANNER_PURGE_DELAY not followed

I don't know...I can't think of anything good. :(  Just looking for 
something more specific as I see other "SMTP Error reading SMTP packet 
NN" error strings that are not related to BANNER_PURGE_DELAY.  (First 
example is with a spfhelo TempFail connection[1].)

In the slave_debug I see the following for the above connection which is 
not very helpful either:

12:17:53.16: Ruleset: EXTERNAL
(Continue reading)

Marko Jauhiainen | 17 Oct 2011 12:50
Picon
Picon

Re: mgrpBroadcasterPolicy(?) puzzle


On 13.10.2011 19:29, Ned Freed wrote:

>> [Running Oracle Communications Messaging Exchange Server 7u4-21.01 64bit
>> (built Feb 16 2011)
>> libimta.so 7u4-21.01 64bit (built 19:04:33, Feb 16 2011)]
>
>> More than a year ago I set up some for-testing-only mailing lists that
>> required the sender to be authenticated before s/he could send mail to
>> the list. Judging by my notes and the documentation I produced at the
>> time, I got everything working more or less just as I expected.
>
>> Now I tried to start using these kind of lists in our production
>> environment but they no longer seem to work the way they worked when I
>> last tested them. I am sure the fault is all mine but since I cannot
>> spot the (obvious?) problem, I wonder if you could help me out a bit
>> here.
>
>> Here is a sample LDAP-entry for a mailing list.
>
>> mgrpMsgRejectText: You need authentication to use this list.
>> mgrpBroadcasterPolicy: AUTH_REQ
>> cn: Test
>> objectClass: top
>> objectClass: groupOfUniqueNames
>> objectClass: nsManagedMailList
>> objectClass: inetMailGroup
>> objectClass: inetLocalMailRecipient
>> objectClass: inetMailGroupManagement
>> mgmanJoinability: none
(Continue reading)

Ned Freed | 17 Oct 2011 18:17

Re: mgrpBroadcasterPolicy(?) puzzle

> > > When sending mail to the list, I get a delivery notification with this
> > > information, even though the sender authenticates himself successfully:

> > > Recipient address: testlist@...
> > > Reason: Remote SMTP server has rejected address
> > > Diagnostic code: smtp;550 5.7.1 You need authentication to use this
> > > list.: testlist@...
> > > Remote system: dns;[111.222.33.444]
> > > (TCP|111.222.33.444|50211|111.222.33.555|10125)

> > It's impossible to tell what's going on without seeing some debug logs, but
> > generally speaking lists that require authentication tend to be very
> > fragile.

> > It's very easy to end up with a hop between the initial submission and the list
> > expansion, and authentication indicators aren't carried over such hops.

> I have "aliasdetourhost" (for virus scanning) in the tcp_auth channel so
> presumably this breaks it?

I assume the detour is via an SMTP hop out and then back in. If so, yes,
this will result in the loss of authentication information - SMTP proper has
means to transport authentication state.

> If so, lists that require authentication are
> indeed very fragile :)

> > (Actually, they can be, but the setup for that is very tricky.)

> Care to elaborate? :)
(Continue reading)

Kristin Hubner | 17 Oct 2011 21:26
Picon
Favicon

Re: mgrpBroadcasterPolicy(?) puzzle

Expanding on Ned's comment (below):

On Oct 17, 2011, at 9:17 AM, Ned Freed wrote:

>> > > When sending mail to the list, I get a delivery notification with this
>> > > information, even though the sender authenticates himself successfully:
> 
>> > > Recipient address: testlist@...
>> > > Reason: Remote SMTP server has rejected address
>> > > Diagnostic code: smtp;550 5.7.1 You need authentication to use this
>> > > list.: testlist@...
>> > > Remote system: dns;[111.222.33.444]
>> > > (TCP|111.222.33.444|50211|111.222.33.555|10125)
> 
>> > It's impossible to tell what's going on without seeing some debug logs, but
>> > generally speaking lists that require authentication tend to be very
>> > fragile.
> 
>> > It's very easy to end up with a hop between the initial submission and the list
>> > expansion, and authentication indicators aren't carried over such hops.
> 
>> I have "aliasdetourhost" (for virus scanning) in the tcp_auth channel so
>> presumably this breaks it?
> 
> I assume the detour is via an SMTP hop out and then back in. If so, yes,
> this will result in the loss of authentication information - SMTP proper has
> means to transport authentication state.
> 
>> If so, lists that require authentication are
>> indeed very fragile :)
(Continue reading)


Gmane