Is this a bug of ims 5.2?
my ims version is 5.2 and hotfix 1.2.5
now, i want to do a limit which make outer domain mail address can not send email to some users of local domain.
So i add a line in the section 'SEND_ACCESS' of the mappings file as so:
SEND_ACCESS
tcp_*|*|*|*@[127.*] $X5.1.2|$NBad$ destination$ system
tcp_*|*|*|*@localhost.* $X5.1.2|$NBad$ destination$ system
tcp_local|*|tcp_intranet|cuiyuming@partner.aaaa.com $N$D30|You_Are_Not_allowed
tcp_local|*|tcp_intranet|postmaster@partner.aaaa.com $N$D30|You_Are_Not_allowed
! Delete the next two items for Direct LDAP mode
! *|*|inactive|* $X4.2.1|$NMailbox$ temporarily$ disabled
! *|*|deleted|* $X5.1.6|$NRecipient$ no$ longer$ on$ server
if set as up, outer mail still can be sent to cuiyuming@partner.aaaa.com
but if i change cuiyuming@partner.aaaa.com to * cuiyuming@partner.aaaa.com, so outer mail can not be sent to cuiyuming@partner.aaaa.com.
I must add the asterisk * before the cuiyuming@partner.aaa.com!
the * is required or is a bug of ims 5.2!
[1089 byte] By [
Robin.Cui] at [2007-11-26 10:03:15]
# 1
Hi,
What do you get when you run the following:
./imsimta test -mapping
Enter table name: SEND_ACCESS
Input string: tcp_local|test@hotmail.com|tcp_intranet|cuiyuming@partner.aaaa.com
This seems to work for me when I use your rule:
# bash-2.05$ ./imsimta test -mapping
Enter table name: SEND_ACCESS
Input string: tcp_local|test@hotmail.com|tcp_intranet|cuiyuming@partner.aaaa.com
Output string: 30|You_Are_Not_allowed
Output flags: [0, 'D' (68), 'N' (78)]
Regards,
Shane.
# 2
Thanks for your reply!
i get the same result when i use imsimta test -mapping!
but when i telnet port 25 as so:
220 partner -- Server ESMTP (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
3 2004))
helo adfasdf
250 partner OK, [10.72.4.255].
mail from:adfa@adfad.com
250 2.5.0 Address Ok.
rcpt to:cuiyuming@partner.aaaa.com
250 2.1.5 cuiyuming@partner.aaaa.com OK.
data
354 Enter mail, end with a single ".".
123123
.
250 2.5.0 Ok.
quit
221 2.3.0 Bye received. Goodbye.
I was very confused by this!
# 3
Hi,You are getting that result most likely because you are coming in on the incorrect channel or the email is going to a channel which you don't expect.What does the log line from mail.log_current for your test attempt you listed look like?Shane.
# 4
mail.log_current as so:
11-Sep-2006 12:31:06.27 tcp_localtcp_intranet E 1 adfa@adfad.com rfc822;cuiyuming@partner.aaaa.com @mstore.partner.aaaa.com:cuiyuming@partner.aaaa.com
11-Sep-2006 12:31:06.67 tcp_intranet D 1 adfa@adfad.com rfc822;cuiyuming@partner.aaaa.com @mstore.partner.aaaa.com:cuiyuming@partner.aaaa.com dns;mstore.partner.aaaa.com (TrendMicro IMSS SMTP proxy) smtp;250 2.1.5 @mstore.partner.aaaa.com:cuiyuming@partner.aaaa.com OK.
the source channel is tcp_local and dest channel is tcp_intranet, i think it is correct?!
# 5
Hi,
I don't know what to tell you except it works for an iMS5.2hf2.14 installation (latest available patch from SUN support):
-bash-3.00$ telnet mumble 25
Trying 1.2.3.4...
Connected to mumble.test.com.
220 mumble.test.com -- Server ESMTP (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006))
helo test.com
250 mumble.test.com OK, gyruss.test.COM [1.2.3.5].
mail from: adfa@adfad.com
250 2.5.0 Address Ok.
rcpt to:cuiyuming@partner.aaaa.com
550 5.7.1 You_Are_Not_allowed: cuiyuming@partner.aaaa.com
The log you supplied seemed fine - the channels and addresses are correct and should have triggered the mapping rule. All I can suggest is that you try a later hotfix (iMS5.2 patch 2) in your test environment to see if you still have the issue and if you do then log a support call. The patch you are running is over 2 years old so chances are if there was a bug it has been fixed.
Regards,
Shane.
# 6
hi,shane,
the problem was solved partially!
i have do as so in SEND_ACCESS section:
tcp_local|*|tcp_intranet|@mstore.partner.huawei.com:cuiyuming@partner.huawei.co m $N$D30|You_Are_Not_allowed
my server have three layers: mta--trend--mstore
that mailbox is on the third layer!
it seems that we must set the rcpt address rewrited...
i download the patch 2,i will test it!
thanks a lot!
# 7
If your relay system allows tcp_local to tcp_local,then something in your configuration is terribly flawed.
Your internal systems should be on tcp_intranet, not tcp_local.
THe name may be confusing, but . .
tcp_local is for EXTERNAL addresses, such as the internet in general
tcp_intranet is for INTERNAL addresses. Yours.
