Friday Jun 22, 2007

Messaging Server HA: Two Nodes Are Better Than One


Two Heads from the Banquet of the Officers (after Frans Hals), by John Singer Sargent

One of our Messaging Server developers just released a feature article that I know will go a long way towards filling a long standing info gap on this subject: Configuring Sun Java System Messaging Server 6.3 With Sun Cluster 3.1 Software. If you want to know how to definitively install and configure a two-node, asymmetric, high availability cluster for Messaging Server 6.3 with Sun Cluster 3.1 software, get the article here.

Tuesday Jun 12, 2007

Extra, Extra, Read All About It: New Messaging Server 6.3 Administration Guide

The Sun Java System Messaging Server 6.3 Administration Guide has just been re-released with many fixes and enhancements, specifically to documenting what we refer to as "MTA Minor Features." Get the book here:

Wednesday Jun 06, 2007

Communications Suite: Confirming That Upgrade Procedure from 5.2

re: upgrading directly from iPlanet Messaging Server 5.2 to Communications Suite 5 (that is, Messaging Server 6.3), the Sun Java Communications Suite Upgrade Guide is clear on the upgrade path:

http://docs.sun.com/source/819-7561/planning.html

To quote:

While it is possible to upgrade all previous releases of Communications Suite software to Communications Suite 5, the only certified upgrades are from Java Enterprise System 2005Q4, Java Enterprise System 2005Q1, and Java Enterprise System 2004Q2. Upgrades from earlier releases are not documented in this Upgrade Guide.

Thus, upgrading directly from iPlanet Messaging Server 5.2 is not a certified way to go. From 5.2, you're supposed to go to 2005Q1 and then from 2005Q1 you can upgrade to 6.3. It's a two-step process. Headache, yes. But that's the certified route to take.

Wednesday May 16, 2007

Messaging Server Upgrade: The Missing Link

Heads up: For those of you patiently awaiting the Messaging Server 6.3 upgrade patch (that is, the patch that will take you from pre-6.3 releases to 6.3), there is news: it should be appearing on SunSolve in the next few weeks. Once it is made available, I'll be sure to alert the Comms community, as well as update the Comms Hub Updates tab.

One other heads up: The patch number will be a different revision than the one initially specified in the C5 Upgrade Guide.

Monday May 14, 2007

Comms Suite: Pull or Push, It's Up to You

Doctor Doolittle's pushmi-pullyu (pronounced "push-me-pull-you")

Traditional email access (dial-up) was and still is "pull" based. You log in to your mail server, your mail client polls the server to see if there is new mail, and if so downloads it to a mailbox in your home directory. The same process happens at regular intervals afterwards as well.

The IMAP protocol, in effect, introduced clients to "push" email. Through support for polling and monitoring of the server, the IMAP protocol enables clients to become aware of new messages, fetch message data, and choose to dowload the message. Wireless devices were next to become 'instant-on' email clients, but used proprietary protocols to achieve that state of bliss.

Now the IETF, in the form of the 'Lemonade Profile,' has provided a standard way to use the existing IMAP IDLE command along with SMTP modficiations for push email.

Communications Suite 5 (released March 2007) supports IMAP IDLE (aka push email). Support for the IMAP and SMTP extensions described in the Lemonade Profile, RFC 4550, is planned for the next major Communications Suite release.

The advantages of IMAP IDLE are:

  • Mail clients do not have to poll the IMAP server for incoming messages.
  • Eliminating client polling reduces the workload on the IMAP server and enhances the server's performance. Client polling is most wasteful when a user receives few or no messages; the client continues to poll at the configured interval, typically every 5 or 10 minutes.
  • A mail client displays a new message to the user much closer to the actual time it arrives in the user's mailbox. A change in message status is also displayed in near-real time.
  • The IMAP server does not have to wait for the next IMAP polling message before it can notify the client of a new or updated mail message. Instead, the IMAP server receives a notification as soon as a new message arrives or a message changes status. The server then notifies the client through the IMAP protocol.

To configure IMAP IDLE in Messaging Server 6.3, see To Configure IMAP IDLE.

Monday May 07, 2007

Messaging Server: More on the War Against Spam

Here's a useful tip for configuring Sun Java System Messaging Server to combat spam: delay sending the SMTP banner for a brief time (half a second, say), then clear the input buffer, and finally send the banner. The reason this works is that many spam clients are not standards-compliant and start blasting SMTP commands as soon as the connection is open. Spam clients that do this when this capability is enabled will lose the first few commands in the SMTP dialogue, rendering the remainder of the dialogue invalid.

This feature has now been implemented in Messaging Server 6.3. You can enable the feature unconditionally by setting the BANNER_PURGE_DELAY SMTP channel option to the number of centiseconds to delay before purging and sending the banner. A value of 0 disables both the delay and purge.

The PORT_ACCESS mapping can also be used to control this capability. Specifying $D in the template causes an additional argument to be read from the template result, after the mandatory SMTP auth ruleset and realm and optional application info addition. This value must be an integer with the same semantics as the BANNER_PURGE_DELAY value. Note that any PORT_ACCESS mapping setting overrides the BANNER_PURGE_DELAY SMTP channel option.

Wednesday Apr 25, 2007

New in Calendar Server 6.3: Event Organizers Can Receive Reply Notifications

The question came up recently about whether the new version of Calendar Server, 6.3, could email notifications to organizers when an attendee replies to an invitation. The answer is YES.

How do you enable this feature? By configuring the ics.confparameter ine.reply.enable. Set it to "y" to enable the feature for the entire system. Set it to "n" to disable the feature. The feature is enabled by default.

The three reply types are: accept, decline, tentatively accept. The notification indicates whether the reply is to a single invitation or to an recurring event. The following new message format file parameters were added. The corresponding format files were also added:

  • calmail.imipeventacceptnotification.fname= "mail_eventacceptnotification.fmt"

  • calmail.imipeventdeclinenotification.fname= "mail_eventdeclinenotification.fmt"

  • calmail.imipeventtentativeacceptnotification.fname= "mail_eventtentativeacceptnotification.fmt"

  • calmail.imipeventacceptnotificationrecur.fname= "mail_eventacceptnotificationrecur.fmt"

  • calmail.imipeventdeclinenotificationrecur.fname= "mail_eventdeclinenotificationrecur.fmt"

  • calmail.imipeventtentativeacceptnotificationrecur.fname= "mail_eventtentativeacceptnotificationrecur.fmt"


Note –

This feature is not a user preference. That is, it is a system wide configuration parameter, so it applies to all users who send invitations.


For more information about configuring Calendar Server for email notifications, see To Enable Email Notifications in Sun Java System Calendar Server 6.3 Administration Guide.

Friday Apr 20, 2007

Sun Java System Messaging Server 6.3: New White Paper

Per a previous post, I alluded to a new white paper out on Messaging Server 6.3. Astute readers alerted me to the fact that I may have, uh, jumped the gun: link not found.

I'm here to report that as of today, this paper is available:

http://www.sun.com/software/products/messaging_srvr/wp_messagingsrvr63.pdf

Friday Apr 06, 2007

More on Installing a Comms 5 Calendar Server 6.3 Deployment (Front End and Back End)

Update, 4/9/07:

A co-worker has correctly pointed out in the comments that I have this not quite right. It is the configurator.sh script itself that is causing the problem. You do not have the option while running the script to choose between IP address and hostname. The script basically choose the IP address rather than the hostname. But again, the fix is afterwards to manually update the ics.conf file for the parameter mentioned below.

- Factotum Management

4/6/07:

As I mentioned in a previous post this week, there's a Calendar Server 6.3 install issue that I want to make folks aware of.

When you use the configurator.sh script to configure your Calendar Server front end, in a front end/back end deployment, as described here, your are supposed to use a fully qualified domain name for the back-end host the front end is pointing to that you will use DWP to commmunicate with. If by mistake you put in an IP address of the host instead, which evidently the script lets you do, the configuration will not work. And then you'll have to manually go back and enter the FQDN of the host instead of the IP address for caldb.dwp.server.backend.ip in the ics.conf file.

And yes, we do have a bug (CR) filed for this.

Tuesday Apr 03, 2007

The Secret Life of Calendar Groups in Calendar Server 6.3 and Communications Express 6.3

We've been having an internal discussion about a 'new' feature in Calendar Server 6.3, namely, Calendar Groups, and how all this fits in with Calendar Server and Communications Express. According to the Calendar Server Release Notes:

Support for LDAP Groups in Calendar Server 6.3

It is now possible to create LDAP groups using Delegated Administrator. Groups have the following functionality:

  • A group is a list of users. The group does not “contain” the listed users. It is not a container.

  • A group can have a group calendar.

  • Invitations sent to a group reside on all the members' calendars, as well as the group calendar.

  • All members of the group share the same access rights to the group calendar.

  • There is no primary owner for a group calendar.

    - This should be corrected to: The group calendar does have an owner, and can have co-owners too.

Clarifying these points, then, with some discussion that took place today:

  • The group calendar that you create through Delegated Administrator is a Corporate Group--different from your usual Personal Group (created through the Communications Express Addressbook).
  • When subscribing to a group calendar through the Communications Express interface, you subscribe to the Personal not Corporate group. That is, the CE interface does not access the group calendar created in the LDAP directory (by using DA).
  • The cscal command manages calendars in the Calendar Database not the LDAP directory. Thus, if you go looking for your LDAP group calendar with cscal, you won't find it initially (see below for more info).
  • When you invite the LDAP group calendar, member calendars added to the group get the events. There is no 'physical' calendar for the group calendar but the individual user's (member's) calendars.
  • To manage a group calendar, you actually manage the member's calendars (in Comms Express).
  • Calendar Groups can be used for limited functionality, including invite to event, check availability, compose mail to group, and view calendar from Addressbook (in Comms Express).
  • Currently, when you create the group calendar, you must then access it the first time (use it in an invite, for example) before it 'shows up' using the cscal command. Unfortunately--and this is a big unfortunately--currently there is no client today with which you an invite the calendar.
I hope this explanation helps in how to use (or not use) the current implementation of group calendars in Calendar Server and Communications Express. Questions anyone?

Monday Feb 05, 2007

New in Messaging Server 6.3: MeterMaid

In the current version of Messaging Server 6.x (and for that matter, 5.x), to limit email coming to the Messaging Server MTA from a particular sending host (IP address), you use the shared library, conn_throttle.so in the Port Access mapping table. Limiting connections by particular IP addresses can be useful for preventing excessive connections used in denial-of-service attacks. This technique is also referred to as "throttling" a host (or IP address).

Messaging Server 6.3 will extend this ability with MeterMaid. MeterMaid enables throttling by determining when an IP address has recently connected too often and should be turned away for awhile. MeterMaid represents the officer patrolling the streets, looking for those who have exceeded their allotted amount. It is a repository process that supplants conn_throttle.so, providing similar functionality but extending it across the Messaging Server product. In addition, MeterMaid is more configurable than conn_throttle.so. Of note: No further enhancements will be made to conn_throttle.so going forward.

Improvements

The primary improvements by MeterMaid are that it is a single repository of the throttling information that can be accessed by all systems and processes within the Messaging Server environment. It continues to maintain an in-memory database to store this data to maximize performance. Restarting MeterMaid will lose all information previously stored, but since the data is typically very short lived, the cost of such a restart (done infrequently) is very low.

Configuration

MeterMaid is accessed from the MTA through a mapping table callout using check_metermaid.so. It can be called from any of the _ACCESS tables. When called from the PORT_ACCESS table, it can be used to check limits based on the IP address of the connection which will be the most common way to implement MeterMaid as a replacement for the older conn_throttle.so. If called from other _ACCESS tables, MeterMaid can also be used to establish limits on other data such as the envelope from or envelope to addresses as well as IP addresses.

Only one entrypoint in check_metermaid.so is defined. The throttle routine contacts MeterMaid providing two subsequent arguments separated by commas. The first is the name of the table against which the data will be checked, and the second is the data to be checked. If the result from the probe is that the particular data being checked has exceeded its quota in that table, check_metermaid.so returns "success" so that the mapping engine will continue processing this entry. The remainder of the entry would then be used to handle this connection that has exceeded its quota.

Again, your definitive source of information on MeterMaid, once 6.3 is out, will be the chapter 19 in the Messaging Server 6.3 Administration Guide.

Friday Feb 02, 2007

Messaging Server 6.3 Spotlight: Messaging Archiving

As we get closer to releasing Messaging Server 6.3 (part of Communications Suite 5), I thought I'd provide a bit more detail on some of the major feature enhancements. This entry focuses on Message Archiving, also known as AXS-One Archiving.

What Is Message Archiving?

A message archiving system saves all or some specified subset of incoming and outgoing messages on a system separate from Messaging Server. Sent, received, deleted, and moved messages can all be saved and retrieved in an archive system. Archived messages cannot be modified or removed by email users so the integrity of incoming and outgoing is maintained.

How Is the Archiving Support Provided?

In 6.3, Messaging Server supports archiving through the AXS-One archive system.

How Is Message Archiving Useful?

There are two ways to look at archiving, compliance and operational. Compliance archiving is used when you have a legal obligation to maintain strict retrievable email record keeping. Selected email (selected by user(s), domain, channel, incoming, outgoing and so on) coming into the MTAis copied to the archive system before being delivered to the message store or the internet. Archiving can be set to occur either before or after spam and virus filtering. Operational archiving is used for mail management purposes, for example to reduce storage usage on the Messaging Server message store by moving less used (older) messages to an archiving system which uses lower cost storage (that is, an alternative for data backup). Note that compliance and operational archiving are not exclusive. That is, you can set up your system so that it does both compliance and operational archiving.

Where Can You Get More Information?

The Messaging Server 6.3 Administration Guide will have overview information on message archiving. The Message Archiving Using the AXS-One System technical note will contain detailed deployment instructions. As usual, you'll be able to get these docs through the docs.sun.com web site, or better yet, through the Communications Suite Hub Library tab.

Note: If you have access to the Beta, you can read the AXS-One technical note now at (sorry for those who don't, it's password protected):

http://docs.sun.com/app/secure/doc/819-6991

About

Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today