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 au

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

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

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

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

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 no

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 (illeg

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 --> Recipien

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

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 simil