gmane.mail.ims.general

Re: problem in messaging server 7 patch 28

David Karnowski — 2013-05-20T17:04:14

Ned,

Any idea when patch 29 is scheduled to be released?

--Dave

On 5/18/2013 2:26 AM, Ned Freed wrote:

Re: problem in messaging server 7 patch 28

Kelly Caudill — 2013-05-20T13:16:50


On 5/18/2013 3:26 AM, Ned Freed wrote:

Yes, I think this email thread is the same issue as reported in bug 16828650.

Kelly

Re: spamfilterX_string_action sieve filter memberof LDAP lookup

Ned Freed — 2013-05-19T01:07:22




Actually LDAP_OPTINx does do what you want. What you'd do is configure two
separate spamfilters, both of which call ClamAV but which handle the results
differently. Then you'd opt different users in to the different scanning
services as appropriate.

The only disadvantage I see to this is that messages sent to multiple
recipients using different services will end up getting scanned twice.




The other way to do this would be to set of ClamAV so all it does is add
the header unconditionally and not do a refuse. You'd then need to have
a system filter that does something like:

require ["envelope", "extlists", "ereject"];
if allof (header :contains "WMU-Virus-Test" "True",
          envelope :list "to" "RECIPIENT_IS_VIRUS_OPT_IN") {
  ereject "Message rejected because it contained malware";
}

See the documentation for how to set up the exlists extension:

   https://wikis.oracle.com/display/CommSuite/Messaging+Server+Support+for+Externally+Stored+Lists+Sieve+Extension


Multiple recipients are handled automatically regardless of the method you use.
I do note, however, that when one recipient rejects the message and another
doesn't the MTA has no choice but to say "250 blah blah" in the SMTP session
and then generate a DSN later. This may be an argument for using discard
instead.

Ned

Re: problem in messaging server 7 patch 28

Ned Freed — 2013-05-18T07:26:01


It's probably bug 16828650 - an interaction between alias file aliases and
aliasdetourhost. It happens on some platforms but not others.

The current plan is to fix this in patch 29.

Ned

problem in messaging server 7 patch 28

Adi Narayana — 2013-05-18T03:20:59

Hello,

I applied messaging server server 7 patch 28 on one of my production
server. Oracle Communications Messaging Server 7u5-28.21(7.0.5.28.0) 64bit
(built Apr 8 2013).

After applying the patch I am not able to send mails to the lists mentioned
in alias file.

If I revert the patch to older version i.e. patch 27, I can send mail to
the list mentioned in alias file.

I have many mailing lists mentioned in the alias file. Is there any work
around to this problem?

Regards,

Adi Narayana

spamfilterX_string_action sieve filter memberof LDAP lookup

Derek Diget — 2013-05-16T16:46:32

I thought that I have seen this before, but I can't find it now. :)

I would like to have a spamfilterX_string_action filter that can 
determine if a user is a member of a certain class/group.

For example ClamAV is integrated via libclamav as a 
sourcespamfilterXoptin on the enqueuing channel, we want all mail to be 
scanned, but certain accounts/addresses to accept messages that contain 
malware like our "report-a-suspect" message address.  So we basically 
have two "virus" class of services.  First, let us call it 
"RECIPIENT_IS_VIRUS_OPT_IN" is the normal (99.999% of users) where a 
message is scanned and rejected (refused) if it tests positive.  Clean 
messages get a header added with $U and passed on.  The second class, 
lets call it "RECIPIENT_IS_VIRUS_OPT_OUT" is where a message is scanned, 
accepted, header added with $U and passed on.  (Note that opt-in or 
opt-out deals more with the action after a messages is scanned, not that 
the user is opt'd-out or -in _for_ scanning.  All messages are to be 
scanned, so a per-user LDAP_OPTINX attribute and LDAP_SPARE_X within 
ORIG_MAIL_ACCESS doesn't really do want we want....well unless someone 
says otherwise. :)

So I have something like the following:

require ["editheader","refuse"];
if envelope :memberof "to" RECIPIENT_IS_VIRUS_OPT_IN {
   addheader"WMU-Virus-Test" "$U";
   if header :contains "WMU-Virus-Test" "True" {
     refuse "Message rejected because it contained malware"
   }
}
elsif envelope :memberof "to" RECIPIENT_IS_VIRUS_OPT_OUT {
   addheader"WMU-Virus-Test" "$U";
}

What ways can I determine if a recipient is a member of one of the 
classes?  Do I have to use extlist or is something else available to 
check if the recipient is a member of RECIPIENT_IS_VIRUS_OPT_IN or 
RECIPIENT_IS_VIRUS_OPT_OUT?  From an LDAP attribute side it would be 
nice to be able to use an attribute on an entry to show if the recipient 
is a member of which class.

I understand I have more work to do, like dealing with multi-recipient 
messages, but right now I am trying to figure out if a I can make an if 
clause evaluate some LDAP attribute value or some other data point 
regarding the recipient.  I know I could probably hard code the couple 
of "opt-out" addresses, but don't want to push the 
spamfilter2_string_action length limit.  Also we might extend this to 
our anti-spam side with letting users set their "reject" threshold.  In 
that case we could have 4-10 different classes.



Thanks.

Hosting the "Info-iMS" mailing list

Steve Arnold — 2013-05-02T05:40:30

Old friends:

Info-iMS-QMRIvgJGioDQT0dZR+AlfA< at >public.gmane.org was set up in March, 2002, to provide a stable place
to discuss the succession of products descended from the iPlanet
Messaging Server. There are currently over 350 subscribers and 100
Mbytes of archives from the last eleven years.

However, I am further narrowing my Internet footprint in retirement, and
specifically, will no longer operate Arnold.com, so I'd like to find a
new place for the list. It's quite basic, really. Anyone with a list
manager could do it. However, it would still need a coordinator to
assist folks in managing subscriptions and culling bad addresses. The
new list owner can either populate the list from the current
subscriptions (recommended) or require new subscriptions. I've managed
to keep the list clean over the years by deleting bad addresses.

There is also the question of the archives. These are in 115 plain text
files in message digest format, one file for each month. This is not as
unreasonable as it seems, as the list has always permitted only plain
text body parts. If folks find these to be useful, they could be stored
for anonymous FTP.

Arnold.com will be transferred no later than June 19. In the mean time,
you may see forward and return addresses in my other domain, Arnold.US.
When the domain is transfered the list will no longer be accessible,
but I'll retain the subscriptions and archives for a few months in case
there is late interest. Contact me directly to arrange the transfer if
you're interested. Thank you!

Regards,
Steve Arnold, Fitchburg Alder, District 4, Seat 7
2530 Targhee Street, Fitchburg, Wisconsin 53711-5491
Telephone +1 608 278 7700 · Facsimile +1 608 278 7701
Steve.Arnold-BvwQI4EktNOh4RqtGuQ/sQ< at >public.gmane.org · http://www.Arnold.US

AUTO : Non-disponible

2013-05-01T14:04:45

Je serai absent(e) du  11/13/2012 au 01/31/2014.

Je ne suis plus employé chez Vidéotron. I am no longer an employee of
Vidéotron

Contactez Ross Beaudoin - please Contact Ross Beaudoin


Remarque : ceci est une réponse automatique à votre message  "Re:
[Info-iMS] MTA fix MIME structure?" envoyé le 05/01/2013 9:15:47.

C'est la seule notification que vous recevrez pendant l'absence de cette
personne.

Re: MTA fix MIME structure?

Jesse Thompson — 2013-05-01T13:15:47

Our user reported back that FormSmarts fixed the problem on their end.

Jesse

Re: MTA fix MIME structure?

Ned Freed — 2013-04-12T15:00:54

Quite possible. Many MTA capabilities, e.g., conversion channel, charset
conversion mapping, thurman chanel keyword, inner channel keyword, require
MIME processing. 

And MIME processing comes in two forms: One where the message is analyzed by
not altered, and the other where it is analyzed and altered. Sieve tests are
the main cases where analysis is done without alteration.


No. Milters happen first, and in parallel, by design. For filtering to work
best it needs to be exposed to the message before any MTA fixups are appled.

If you want to have milters apply to filtered content you have to arrange
additional channel hops. Similarly, if you want one milter to see the output
of another you also need additional channel hops.


I've seen what I'd consider bulk commercial mail with invalid CTEs, but I don't
recall a case of outright spam having one. So it may be a case of an invalid
CTE being an indication of legitimacy...

Ned

Re: MTA fix MIME structure?

Jesse Thompson — 2013-04-12T14:27:11


On 4/11/2013 1:44 PM, Ned Freed wrote:

As far as I am aware, only our milter (PureMessage) is the only 
component that does MIME processing.  Maybe we doing MIME processing in 
some other unbeknownst way by means of using some other feature.

So, that makes me wonder.  Does the "fixed" version of the message get 
sent to the milter (sourcespamfiter on the inbound channel)?  I wonder 
if I should consult with someone at PureMessage to determine if 
ignoremultipartencoding is better or worse.  Their spam rules might be 
depending on spam messages having invalid CTEs.

Jesse

Re: MTA fix MIME structure?

Ned Freed — 2013-04-11T18:44:44


"Correctly" isn't quite the right word. Encodings are presently forbidden on
mulitparts - if you have a CTE field, it has to specify either binary, 8bit
or 7bit. 

The question is whether or not the header actually means the part is encoded.
But it's illegal in either case.


That again depends on whether or not you're doing MIME processing. If you
do MIME processing the header should be removed regardless of the option
setting. Of course if the option setting is wrong you end up with garbage.

Ned

Re: MTA fix MIME structure?

Jesse Thompson — 2013-04-11T17:06:42

So, the risk of enabling ignoremultipartencoding is that messages that 
are encoded correctly won't be decoded?  Does that just kick the problem 
to the MUA?  So, it's only a problem when the MUA also decides to ignore 
multipart encoding?

Jesse

Re: MTA fix MIME structure?

Ned Freed — 2013-04-11T15:03:59

Milter debugging would tell you, of course. You'd see a "change body" 
result being retured. But aside from that, no, there's no way to log it from
the MTA side.


I would hope that anything having to do would security like this would have
fairly comprehensive logging capabilities of its own.

I suppose we could add something to do it. But since we have no way of knowing
*why* a milter did what it did, any capability we add is going to be inferior
to whatever milter did.



No. In fact there's nothing a milter can do that would necessarily trigger
MIME processing on the part of the MTA.




Er, no. We're both assuming the FormSmarts people are correct when they say
they're emitting a bogus CTE and that this is due to a library bug they are
unable to fix. FWIW, we've seen this before; in fact it's been discussed on
this list several times.

If you want to verify this you need to enable debugging to capture a message:
slave_debug with MM_DEBUG set to 5.


The instant any other mail service touches the message it's of use use for
diagnostic purposes. This is always the case, but it's especially true when
dealing with invalid material.


Even that is not sufficient. For all you know the message was fixed
by some other agent before it reached the end user.

Debugging is really the only way to be sure what you are getting.



Of course that is your choice. But the reality on the ground right now is that
multiparts with meaningless CTEs are more prevalent than ones with
meaningful CTEs. By not setting the option to match that reality, you
are in effect setting yourself for suboptimal handling of a certain kind of
malformed mail.

And yes, this really sucks. But you heard it from the people who are apparently
responsible: They claim not to be able to fix it. This actually explains
why we're seeing so much of this right now, but of course it does not excuse
it.

Ned

Re: MTA fix MIME structure?

Jesse Thompson — 2013-04-11T14:31:04

Mostly, I'm just curious if there is a way to tell when the MTA/milter 
does modify the MIME structure.

I know that the milter decodes the MIME for all messages as part of its 
scanning process.  We do have PureMessage configured to add, remove or 
modify MIME when in specific situations.

But in this case it only added a header.  According to the mail log, the 
milter did this: 'system:, keep, addheader'

Does an 'addheader' trigger MIME processing?



I'm willing to assume that you're right, but I don't have any direct 
evidence what the original CTE was.  I did obtain a version of the 
message that was sent to a user on another email service (and was 
readable by the user).  The CTE looked the same as the broken message. 
But the message was forwarded to me as a MIME attachment, so I assume 
that it is possible that the attached message suffered the same 
modification by our MTA/milter.  I suppose that the user will need to 
zip-up the message source before sending?



Right.  I don't envision a need to change this option.



Thanks, as always, for your detailed response.  Kristin and Leonard too!

Jesse

Re: MTA fix MIME structure?

Ned Freed — 2013-04-09T21:30:28

Nothing odd about it, really. You apparently have the MTA set to perform some
type of MIME processing. That necessarily means that the MIME structure is
going to be parsed and, depending on what options you have selected, possibly
modified.

An unavoidable consequence of this is that if the message has an invalid
structure to begin with, the result is not going to be good. We have a term for
this: GIGO.

The best solution for this is - gasp - to stop sending invalid crap around to
begin with. There is simply no excuse for sending out invalid MIME at this
point in time. 20 years should be long enough to get it right.

Of course if would be different if our MTA is misinterpreting valid MIME in
some way and making it invalid. But that is why we have standards: Show us the
incoming message, demonstrating it is valid, and if there's a problem with our
handling we'll fix it. And if it isn't we may even try to accomodate it.





Milter certainly has the ability to change the message content, although FWIW
I've noted it being used sparingly by antispam software.




...

If the remainder of this message is correct, this message had a bogus
"Content-transfer-encoding: quoted-printable" on the multipart. CTEs are
categorically disallowed for multiparts by MIME. Note, however, that this is no
longer the case for the message top-level type. EAI has changed the situation
there and as you might expect, the standards say to honor the CTE, not ignore
it.

When such a header does appear on a multipart (or message) entity there are two
possibilities: (1) The entity is encoded as the header says or (2) It isn't;
the header is meaningless. Someone processing has to choose which one to
implement. (1) used to be pretty common but more recently (2) has been the one
we commonly see.

Our MTA has source channel keywords to handle either case (1)
(interpretmultipartencoding) and (2) (ignoremultipartencoding). So all you have
to do is set things to match what you're seeing. Of course if you're seeing
both you're kinda screwed, which is why the best solution is for senders to
follow the standards.



Er, no. Changing the boundary marker has absolutely no consequence in MIME; the
specific value of the string is assigned no semantics. In fact the only way to
do single pass processing of MIME material is to change all the boundaries
unconditionally as you process. This is an inherent part of the design that
Nathaniel Borenstein, Mark Crispin, and I worked out back in 1990 (in a funky
restaurant in St. Louis, FWIW).

The only requirement is that the string has to be syntactically valid and used
consistently. It's only when that's not the case that problems occur. And one
of the ways for that to happen is for an encoding to incorrectly specified for
the multipart.



And the only reason the MTA would do that is if the data was marked as being
encoded but in fact was not.


And in so doing is emitting flagrantly invalid MIME. Since as it happens I
wrote the relevant text in MIME, I can assure you there's no provision nor any
hidden intent saying it is OK to have a bogus CTE on a multipart. 



Ahem. I rather think that's my point to make, not FormSmart's. I see no way "be
conservative in what you emit" can be construed to cover the emission of
illegal crap, which is what is going on here.

As for being liberal in what you accept... the fact of the matter is that
handling nested encodings in a single pass (which our MTA is capable of doing,
and yes, it has been seen in the wild) was quite difficult to implement and we
went to a lot of trouble to do it. And the reason we did that was to honor this
principle, because at the time we implemented this handling the CTE headers we
saw on multiparts were without exception indications of an actual encoding
being present. And when we started to see instances where the CTE was present
but needed to be ignored, we once again honored the principle and added support
for that.


Goodness gracious, what a novel idea! I never thought of that.

Oh wait, I did. Right around the time I implemented ignoremultipartencoding,
which was some years back. It was the obvious thing to do, so of course I
considered it.

The problem is it is a lot trickier to do than it sounds. It has to be done as
a preprocessing pass - which is not a problem in and of itself. But in order to
do it efficiently and comorehensively it requires maintaining a stack of points
to back up to. And note that due to the possibility of nested encodings
"backing up" is nowhere near as simple as moving a file pointer. You're talking
about backing up an arbitrary number of encoding states to a previous point.
And those encoding states can include compression libraries and even decoding
of tarballs... Is everyone beginning to get the picture here?

The bottom line is I really cannot justify the considerable engineering and QA
time to accomodate what is, after all, a problem that is best addressed by
fixing the broken client that is actually, you know, repsonsible.

There is an obvious alternative, which is what I'll do if both forms become
sufficiently prevalent that this is a problem that needs to be solved. The
alternative is rather than backing up to the start of the multipart or message
part, note the problem and the part where it occurred. And when you're done,
if you've found any parts with invalid CTEs, then start over. (The reason
you don't back up immediately is the most likely case where there are
more than one of these parts is a digest where they are all at the same level.)

And since this has a failure case were a deeply nested set of bogus CTE can
cause backing up to occur an unacceptable number of time, you only do that
once. (Or maybe twice.)

This isn't all that easy to do either, but it's certainly a lot easier than the
comprehensive solution.

Ned

Re: MTA fix MIME structure?

Kristin Hubner — 2013-04-09T21:37:14

(Resending with corrected From: address)

As the other vendor admits, they are emitting a technically illegal message:

For message parts and multiparts, the only legal (per RFC 1521 or its update 2045)
Content-transfer-encoding: values are the "identity" values 7BIT, 8BIT, or BINARY in general, 
with with the particular message subtypes message/partial and message/external-body being 
further restricted to allow only 7BIT.  

The original MIME standard (RFC 1521, dating from 1993) forbid putting any other encodings
on such parts; and RFC 2045, the update, has the same sort of wording in Section 6.4:

If an entity is of type "multipart" the Content-Transfer-Encoding is not permitted to
have any value other than "7bit", "8bit" or "binary".

Nevertheless, buggy/incompliant software may sometimes emit messages that
illegally label multipart or message parts as having another
content-transfer-encoding. Now when such an illegal encoding label is seen,
the question is whether the material is in fact encoded (illegally) as claimed,
or whether the material is not in fact encoded and the claim is simply false.
As always, the best solution is to fix the broken software emitting such
bogus messages to emit legal, correctly labelled, messages instead.

The MTA's default handling (and the only handling available prior to MS 6.3) is
to believe the Content-transfer-encoding: label---and the MTA can (and will)
"decode" such messages. This corresponds to the default "interpretmessageencoding"
and "interpretmultipartencoding" keywords. This leads to "successful" handling of
messages that are broken due to illegally being encoded---but will not be equally
satisfactory for messages that are broken due to an outright false labelling with
the contents not actually being encoded.

Alternatively, the new in MS 6.3 "ignoremessageencoding" and "ignoremultipartencoding"
channel keywords, when placed on a source channel, will cause the MTA to ignore any
claimed Content-transfer-encoding: on message/rfc822 parts or multipart parts,
respectively, which can be more useful when broken software is emitting messages
that falsely claim encoding of such parts. (Note that since the permitted and legal
7BIT, 8BIT, and BINARY content-transfer-encodings are all identity encodings---no
transformation of the data is involved, with the content-transfer-encoding label
merely recording what sort of material the part contains, which the MTA can determine
for itself---it causes no harm to RFC 2045 conformant message or multipart parts to 
ignore the content-transfer-encoding.)

HOWEVER, be aware that the experimental EAI (Email Address Internationalization) 
specifications are likely to change the MIME restriction on encodings on multiparts
and message parts, and ALLOW such encodings.  At such time as such specifications in
fact are published and email taking advantage of it starts going around, support for
correct messages would then require respecting and interpreting encodings on such parts; 
that is, our MTA's default "interpretmessageencoding" and "interpretmultipartencoding" 
keywords will then become the only "correct" behavior if you wish to support more 
up-to-date e-mail systems.

This makes it especially important that mailers such as the broken one you are
apparently encountering FIX their software to comply with the (seventeen year old)
rules on MIME encoding: while their brokenness can be worked around without harm 
to correct messages at that moment, that is likely to cease to be the case in 
future with a future choice being between supporting their broken behavior, vs.
supporting correct behavior to support more advanced email features.  Or if you
can detect which sources emit the broken messages, you can set up a special
source channel and special [<ip-source>] $E$R sorts of rewrite rules to force their
messages to the special source channel, and mark just that source channel with the
"ignore*" keyword(s).

Note that the imsimta test -mime utility has switches for testing and describing the
(MIME) structure of messages, switches which correspond to the channel keywords
mentioned (e.g., -iemultipart meaning "interpret encoded multipart" and
-noiemultipart meaning "ignore encoding on multipart").

Regards,

Kristin
On Apr 9, 2013, at 12:12 PM, Jesse Thompson wrote:

Re: MTA fix MIME structure?

Leonhard Knauff — 2013-04-09T20:44:54

Every MTA is allowed to convert the coding of the message resp. each body part.
(The content self are not allowed to change.)

Examples:
  1. Changed coding (also iMS has the CONVERSIONS and CHARSET-CONCVERSION
     in the mapping files):
       + The original boundary string now can be inside the new coded text.
       + Therefore the MTA _must then_ generate a new boundary string which 
         is not then part of the new codung.
  2. The (modern but not used) X.400 mail protocol:
       + In X.400 there are no MIME and no boundary string, because there
         are body types like "image", "fax" ... which were original binary.
       + We (uni-halle.de, and DFN German Research Network) uses X.400
         and SMTP parallel from 1990 to 2000.
       + In this scenario the transport chain can be:
           Sender --> SMTP with MIME --> MailGateway1 SMTP/X.400 --> 
                  -->     X.400      --> MailGateway2 X.400/SMTP -->
                  --> SMTP with MIME --> Mailserver recipient --> Recipient
       + So "MailGateway1 SMTP/X.400" converts "MIME" to X.400 (all MIME 
         bodyparts are converted to X.400 body parts without boundary strings,
         all original MIME boundary strings are deleted.
       + Then "MailGateway2 X.400/SMTP" must for the SMTP transport in the 
         next step generate new own boundary strings.
       + It can be too:
            X.400 --> SMTP with MIME --> X.400 --> SMTP with MIME --> ....

Sorry, then some check sums ff. are corrupted  :-(((

Regards,
Leonhard

[.....]

MTA fix MIME structure?

Jesse Thompson — 2013-04-09T19:12:27

We've got an odd situation where our MTA (allegedly) is modifying the 
MIME structure of some incorrectly structured messages.  Or maybe it's 
the milter doing it?  Or maybe

Any comments regarding the appropriateness of the MTA/milter fixing 
incorrectly structured MIME messages in transit?

spamfilter1_library=...libmilter.so
spamfilter1_config_file=...milter.opt
spamfilter1_string_action=data:,$M
spamfilter1_optional=0
spamfilter1_final=2

MTA version is 7u4-26.01

milter is PureMessage 5.  As far as I can tell from the logs, 
PureMessage did not intentionally modify the message (strip a virus 
part, or whatever).

Here is the message as received (modified form) by the recipient:

<snip headers>
MIME-version: 1.0
Content-type: multipart/alternative;
  boundary="Boundary_(ID_UgfE+cHbb0j1JWMh6bZdTg)"; charset=utf-8
<snip headers>

--=======G88546249933746096=
Content-Type: text/plain; charset"us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit


Your email client doesn't support HTML emails. Either change the
configuration of your email client to display HTML messages, or
change the email format to plain text in FormSmarts settings.
--=======G88546249933746096=
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset"utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
<snip lots of html>

--=======G88546249933746096=--

--Boundary_(ID_UgfE+cHbb0j1JWMh6bZdTg)--


Here is what the sending party (FormSmarts) said:

"
The inconsistency in message part boundaries mentioned by the wisc.edu 
administrator is indeed the main reason why the message appears blank 
(besides this, the HTML body was altered and rendered invalid). This is 
the outcome of the mail transfer agent (MTA), Oracle Communications 
Messaging Server on wmstore3pvt.pri.doit.wisc.edu changing the boundary 
in the Content-Type header.

The original boundary "=======G88546249933746096=" was changed to 
"Boundary_(ID_UgfE+cHbb0j1JWMh6bZdTg".

The MTA broke the original message boundary and HTML body by attempting 
to decode non-encoded data. It subsequently replaced the original 
boundary in the header, failing to do so within the message body.

As per MIME 1.0 standards, the main body of multipart messages cannot be 
encoded (unlike individual parts) to prevent issues that would arise 
with multiple levels of encodings. So the MTA shouldn't attempt to 
decode messages. FormSmarts doesn't encode data at the message level, 
however due to a bug in the email library we use to generate messages, 
our software will add an encoding header, suggesting it does encode data 
at the message level.

The bug in the messaging library was first reported in 2008 and the fix 
still hasn't yet made it to the production version of the library 
because it is basically harmless (besides being a violation of the 
standards).

A well-know and honored principle in Internet software is to "be liberal 
in what you accept, and conservative in what you send" (Postel's Law).

Accordingly, most MTAs will simply ignore the bogus encoding 
declaration. Oracle Communications Messaging Server fails by breaking 
the message, not even bothering backtracking once it has become clear 
that the message wasn't encoded in the first place since decoding leads 
to an empty-looking message.
"

Netapp data stores

Peter Kaldis — 2013-03-18T16:45:05

Hi everyone, just trying to do some due diligence. Our environment consists of messaging servers running a mix of 7u4-20.01, and 6.3-16.01, and NetApp filers for actual mailbox data storage. The current filers have OS v 7.X, but we are looking  to upgrade to some faster heads. The new NetApp filer heads come with NetApp OS v 8.X. Oracle support says that they don't qualify filers with the messaging server, so they cannot tell me if there are any issues with this newer NetApp OS release. If any of you folks might already be using this combo in your own environment, I'd appreciate hearing about your experiences. 

Thanks!

-Peter Kaldis

Re: reprocess channel - how to not inherit transactionlimit?

Kristin Hubner — 2013-03-12T22:32:57

On Mar 12, 2013, at 12:27 PM, Jesse Thompson wrote:


Correct: ALLOW_TRANSACTIONS_PER_SESSION, like other SMTP-server-affecting options in 
tcp_local_option, applies to all SMTP sessions that originally got handled by tcp_local,
even if the session later "switches" to a different incoming tcp_* channel.

This is why "transactionlimit" and other channel keyword of the tcp_local options 
were originally added: to be able to make the effects specific to an incoming 
"switched to" channel, rather than globally applying to all port 25 SMTP sessions.


No, you can't avoid that effect of ALLOW_TRANSACTIONS_PER_SESSION.

Until you have one of Ned's new features (e.g., in future version, "transactionlimit"
specifically exempted from reprocess channel "carry over" from prior channel), the
best I can suggest is that you could consider setting "disconnecttransactionlimit"
instead of "transactionlimit" on whichever tcp_* channels you're wanting the 
transaction limit on.

This is because despite the names being so similar, and in some ways the effect being
quite similar, "disconnecttransactionlimit" and "transactionlimit" are implemented
rather differently, "disconnecttransactionlimit" applying specifically when the SMTP
protocol is being used, whereas "transactionlimit" applies more generally to all
enqueueing (and so even when reprocess or other internal channel are running).  So if
you set "disconnecttransactionlimit" on the incoming tcp_* channels, I believe it should
only affect that SMTP session, and not end up resulting in any "carry over" to the 
reprocess channel.

But "disconnecttransactionlimit" is more drastic, in that it causes the SMTP server to
forcibly disconnect the session.  While any SMTP client that wants to cope with reality 
needs to be able to cope with a network connection getting dropped, or an SMTP server 
going away, it's possible that "fragile" SMTP clients (especially lightweight clients
performing initial message submission for users) might not handle it as gracefully as
one might wish.  "disconnecttransactionlimit" is intended more for cases of suspected
spammers where you don't care if the session disconnect "bothers" the SMTP client; but
if you're applying it in a case of relatively "friendly" (just overly chatty) 
correspondents, I recommend some initial monitoring to make sure it isn't resulting in 
problematically quirky SMTP client behavior pushback at your correspondents.

Regards,

Kristin