headers
R.E.Sonneveld | 2 Sep 2009 13:31
Picon

Question on local channel program

Hi,

Running:
Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)
libimta.so 6.3-8.01 (built 17:45:10, Dec 16 2008; 64bit)
SunOS hostname 5.10 Generic_138888-08 sun4u sparc SUNW,Sun-Fire-V210

It seems after a fresh install the job_controller.cnf does not contain a section for the local channel,
while the imta.cnf does, is that correct? The l channel definition looks like:

!
! delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7
domainname

I would expect a section like:

[CHANNEL=l]
master_command=IMTA_BIN:l_master

in the job_controller.cnf, but it's not there. Is there any risk in adding this section to the
job_controller.site? I tested with mail to the local root account, which had a .forward and before adding
this section mail was stuck in the queue (l channel) without delivery attempts, and after adding this
CHANNEL=l section, and a restart the mail was delivered correctly and the .forward entry was honoured.

/rolf
Permalink | Reply | 5 comments |
headers
Chris Newman | 2 Sep 2009 18:48
Picon

Re: Question on local channel program

The job_controller.cnf should contain a section for the native channel, 
like the following:

!
[CHANNEL=native]
master_command=IMTA_BIN:l_master

just after the ims-ms channel.  The native channel is used for delivery to 
Unix /var/mail style mailboxes.

		- Chris

--On September 2, 2009 13:31:28 +0200 R.E.Sonneveld@... wrote:

> Hi,
>
> Running:
> Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)
> libimta.so 6.3-8.01 (built 17:45:10, Dec 16 2008; 64bit)
> SunOS hostname 5.10 Generic_138888-08 sun4u sparc SUNW,Sun-Fire-V210
>
> It seems after a fresh install the job_controller.cnf does not contain a
> section for the local channel, while the imta.cnf does, is that correct?
> The l channel definition looks like:
> !
> ! delivery channel to local /var/mail store
> l subdirs 20 viaaliasrequired maxjobs 7
> domainname
>
> I would expect a section like:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rolf E. Sonneveld | 2 Sep 2009 22:08
Picon

Re: Question on local channel program

Chris Newman wrote:
> The job_controller.cnf should contain a section for the native 
> channel, like the following:
>
> !
> [CHANNEL=native]
> master_command=IMTA_BIN:l_master
>
> just after the ims-ms channel.  The native channel is used for 
> delivery to Unix /var/mail style mailboxes.

But then I can't understand why delivery to the local channel did not 
complete, until I added the CHANNEL=l section. To clarify things: I saw 
the 'enqueue' record in the log file for the l channel, but no 
'dequeue'. Using 'qm> dir' the message filenames started with ZZ* and 
there was no delivery history. Adding the CHANNEL=l solved it, or maybe 
it was just the restart of the job_controller that made the delivery 
complete? Anyway, the CHANNEL=l should not be in job_controller.cnf and 
the CHANNEL=native should be present, I understand. I'll check.

/rolf
Permalink | Reply | 3 comments |
headers
Kristin Hubner | 2 Sep 2009 23:51
Picon

Re: Question on local channel program

Keep in mind that when it comes to the "l" channel, the JES MS MTA  
usage is
very different from PMDF.

In particular, for the JES MS MTA, the "l" channel is _never_ supposed  
to be
used to perform actual delivery: instead, it exists solely as a  
placeholder
channel on which to perform alias expansion.  If you want to actually  
_deliver_
to a Unix /var/mail mailbox, you are supposed to use an address that  
matches
the "native" channel.  Or better yet, what you're really supposed to  
do is
use an address that has mailDeliveryOption: native set.

On Sep 2, 2009, at 1:08 PM, Rolf E. Sonneveld wrote:

> Chris Newman wrote:
>> The job_controller.cnf should contain a section for the native  
>> channel, like the following:
>>
>> !
>> [CHANNEL=native]
>> master_command=IMTA_BIN:l_master
>>
>> just after the ims-ms channel.  The native channel is used for  
>> delivery to Unix /var/mail style mailboxes.
>
> But then I can't understand why delivery to the local channel did
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rolf E. Sonneveld | 3 Sep 2009 07:40
Picon

Re: Question on local channel program

Kristin Hubner wrote:
> Keep in mind that when it comes to the "l" channel, the JES MS MTA 
> usage is
> very different from PMDF.
>
> In particular, for the JES MS MTA, the "l" channel is _never_ supposed 
> to be
> used to perform actual delivery: instead, it exists solely as a 
> placeholder
> channel on which to perform alias expansion.  If you want to actually 
> _deliver_
> to a Unix /var/mail mailbox, you are supposed to use an address that 
> matches
> the "native" channel.  Or better yet, what you're really supposed to 
> do is
> use an address that has mailDeliveryOption: native set.

thanks, this is exactly what I was looking for, thanks. Delivery has to 
be done to 'root', where the sysadmin (who does not administer the mail 
application) is able to determine the final recipient by way of a 
.forward file for the root account.

/rolf
Permalink | Reply | 1 comment |
headers
frederic Van De Velde | 3 Sep 2009 10:21

UWC and OpenSSO 8.0

Hi,

I'm trying to integrate UWC to single sign-on with OpenSSO 8.0 and  
facing some problems.

Convergence works perfectly with OpenSSO 8.0 but for UWC I'm facing  
some problem with cookie encoding.

Did someone already succeed to do it ?

Regards,
Frederic.
Permalink | Reply | 7 comments |
headers
Kristin Hubner | 4 Sep 2009 01:28
Picon

Re: Question on local channel program

Whatever the "externally" visible address may be, note that setting
mailDeliveryOption: native will then cause native delivery to the uid  
value
for the account with that address (see the DELIVERY_OPTIONS option.dat
option's setting for the "native" clause) -- or if that externally  
visible
address doesn't have the uid root, maybe you want to set the  
externally visible
address to forward (mailDeliveryOption: forward,
mailForwardingAddress: <address-that-does-have-root-uid>) and then the
account that has root uid would have mailDeliveryOption: native set, and
then can do whatever redirecting you wish via a .forward file for the  
root
account.

Regards,

Kristin

On Sep 2, 2009, at 10:40 PM, Rolf E. Sonneveld wrote:

> Kristin Hubner wrote:
>> Keep in mind that when it comes to the "l" channel, the JES MS MTA  
>> usage is
>> very different from PMDF.
>>
>> In particular, for the JES MS MTA, the "l" channel is _never_  
>> supposed to be
>> used to perform actual delivery: instead, it exists solely as a  
>> placeholder
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leonhard Knauff | 5 Sep 2009 22:02
Picon
Favicon

Qouted-Printable & Character "=" in mime boundary

Hallo,

Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug  4 2008; 32bit)
libimta.so 6.3-7.03 (built 11:22:04, Aug  4 2008; 32bit)
SunOS mserv3 5.10 Generic_127111-02 sun4v sparc SUNW,SPARC-Enterprise-T2000

Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)
libimta.so 6.3-8.03 (built 18:51:22, Apr 24 2009; 32bit)
SunOS mlucom12 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-280R

 ???  What is in SJS Messaging Server ?

My problem:

  >> A character "=" in a mime boundary string of an incoming message
  >> is processed wrong, and the mime structure is destroyed.

  RFC2046 says:  "=" is an allowed character.

        boundary := 0*69<bchars> bcharsnospace
            bchars := bcharsnospace / " "
            bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                             "+" / "_" / "," / "-" / "." /
                             "/" / ":" / "=" / "?"

The problem:
------------

Our users get electronic documents from SUBITO.  The documents (pdf files)
are send via e-mail, of course in MIME structure.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kristin Hubner | 5 Sep 2009 22:46
Picon

Re: Qouted-Printable & Character "=" in mime boundary

The problem here is that the incoming message is illegal.  The  
illegality
is not the "=" character in the boundary which as you observe, is a  
legal
character in MIME boundary markers.  Rather, the illegality is the

Content-transfer-encoding: quoted-printable

being set on a multipart as in your sample message:

>   From subito@... Fri Sep 04 12:39:33 2009
>   Return-path: <subito@...>
>   .....
>   Content-Type: multipart/mixed; charset="iso-8859-1";
>     boundary="=_3a84758c9b06dc7c90874e5b2cd4452f"
>   Content-Transfer-Encoding: quoted-printable
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 From RFC 2045, Section 6.4:

   Certain Content-Transfer-Encoding values may only be used on certain
   media types.  In particular, it is EXPRESSLY FORBIDDEN to use any
   encodings other than "7bit", "8bit", or "binary" with any composite
   media type, i.e. one that recursively includes other Content-Type
   fields.  Currently the only composite media types are "multipart" and
   "message".  All encodings that are desired for bodies of type
   multipart or message must be done at the innermost level, by encoding
   the actual body that needs to be encoded.

Now there are two possiblities when this sort of syntactically illegal
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ned Freed | 5 Sep 2009 22:36

Re: Qouted-Printable & Character "=" in mime boundary

> Hallo,

> Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug  4 2008; 32bit)
> libimta.so 6.3-7.03 (built 11:22:04, Aug  4 2008; 32bit)
> SunOS mserv3 5.10 Generic_127111-02 sun4v sparc SUNW,SPARC-Enterprise-T2000

> Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)
> libimta.so 6.3-8.03 (built 18:51:22, Apr 24 2009; 32bit)
> SunOS mlucom12 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-280R

>  ???  What is in SJS Messaging Server ?

> My problem:

>   >> A character "=" in a mime boundary string of an incoming message
>   >> is processed wrong, and the mime structure is destroyed.

The MIME message you are dealing with malformed: It has an illegal
content-transfer-encoding on a multipart. The MIME specification expressly
forbids this.

There is no "right" or "wrong" involved when dealing with malformed material;
there's only "it works" or "it didn't work". When it comes to nonidentity
encodings applied to multiparts and nested messages, what works is for
processing to match whether or not an encoding is actually present. In
practice, sometimes one is, other times it is not. The MTA's default is to
assume the header isn't lying and remove the encoding, but in this particular
case that default doesnt' work because the header is lying and no encoding is
acctually present.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane