How mail come in diff Channel?

Thanks Jay.

I know, but I want to deal with them diff. My company user are real internal user, don't need auth. But friend site need auth, because friend site is dialup pool, other ISP also use the pool, then other ISP's client may use my email server, that is we don't want it happen, so that I have to make them go diff channnel. OR you have better idea?

It is too easy to fake some one in your org, for example postmaster@yourdomain.com, to send spam out. so that I have to use AUTH SMTP.

Jay, in other post, you reply "Once you assign your ip to $N in internal_ip, you're not likely to do anything with friend_ip."

I don't understand this. Do you mean my IP will site in internal_ip pool for every as long as IMTA alive? When I assign my ip to $N in internal_ip, and assign $Y in friend_ip, so it IS one of friend_ip, when dispatcher parse PORT_ACCESS table, it did found my IP is in friend_ip range, I can told by output of test -mapping. Why it did not let tcp_friend come to handle it? I believe this rewrite rule should tell dispatcher start tcp_friend-daemon to handle this mesg.

[] $E$R${FRIEND_IP,$L}$U%[$L]@tcp_friend-daemon

am I right?

Also I am wondering how to block web mail client spamming out side world. Default setting, web mail come from 127.0.0.1, that is internal_IP SpamAssassin shold catch him, right?

BTW, sourcespamfilterXoptin and destinationspamfilterXoptin, which one I need to use?

As I understand, if I filter on ims-ms channel, I should use destinationspamfilterXoptin, b/c msg go into the channel.

if I filter on tcp_local, tcp_intranet, tcp_friend channel, I should use sourcespamfilterXoptin, that will scan come in from internet and go out to internet mesg, right? I stll have a bit confusion about direction, enqueue/dequeue.

Jerry_Goconnect at 2007-7-7 2:43:10 >

That is our very special case.

We are offer our client webmail and pop access via our upstream ISP dyna IP pool. New client can sign up via our web site.

We found some spammers sign up from Europe and USA, and he got username and password straightway, then he use webmail or smtp to spam. Then we tie up web access, only turn on web access after we verify that is a real local person.

But SMTP we are not going to do that. We give the client smtp access

once he sign up.

Say a spammer in Europe, sign up, we don't want he is able to use our mail server spamming via AUTH SMTP, only thing we can do is checking his IP, outside our upstream ISP IP range, then we block him. right?We once turned one AUTH SMTP in NMS4.1 before, after 2 week, have to shut it down, due to dramatically increased spammers.

So, We can not do AUTH SMTP for all of the world, only for limited IP range. We only serve local community, no like hotmail, yahoo mail. We don't give our user roaming SMTP, instead web mail.

That is reason, we don't turn on tcp_local AUTH SMTP feature, only turn on AUTH SMTP in small IP range, let them go throught tcp_friend channel.

Local spammer is much easy to trace dowm, but some one from other country, 99% just close your eye, I personally just delete spam. we don't want our mail server list in RBL.

I don't know what is going wrong, even webmail (127.0.0.1) can not send mail out internet, except addressed to local domain, mesg enqueue throught tcp_local channel, of course it can not back out tcp_local channel again. must be imta.cnf error.

Jerry_Goconnect at 2007-7-7 2:43:10 >

I suspect that you've broken your mappings file

It is sensitive to spacing, and whitespace.

Each table has to have blank lines above/below

each table entry needs white space at the beginning of the line.

If you can't get it figured out, please contact Tech Support. They will have you send them the actual mappings file.

jay_plesset at 2007-7-7 2:43:11 >

no any luck, Shane, I have been locked!

even 120.0.0.1(sent by web mail client) become external IP, gone throught tcp_local channel, have been totally blocked.

I don't know what is problem, even I remove friend ip range, back to single internal ip table, make sure 1 blank line between tables, 1 blank line between table name and entry, 2 spaces in front of each entry, indented lines, cnbuild restart .......still not work.

test -mapping always get correct result, but send mail always go to tcp_local.

Now I think imta.cnf may be have problem. does rewriting rule control mesg enqueue channel, right?

! Rules to select local users

$* $A$E$F$U%$H$V$H@melpop02.goconnect.net

melpop02.goconnect.net $U%$D@melpop02.goconnect.net

goconnect.net $U%$D@melpop02.goconnect.net

!

! tcp_local

! Rules for top level internet domains

<IMTA_TABLE:internet.rules

!

! tcp_intranet

! Do mapping lookup for internal IP addresses

[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

.goconnect.net $U%$H.goconnect.net@tcp_intranet-daemon

* $U%$&0.goconnect.net

!

!

! tcp_local

tcp_local smtp mx single_sys inner identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL missingrecipientpolicy 0 mailfromdnsverify backoff "pt30m" "pt2h" "pt4h" sourcespamfilter2optin spam sourcespamfilter1optin spam

tcp-daemon

! tcp_intranet

tcp_intranet smtp mx single_sys subdirs 20 maxjobs 7 pool SMTP_POOL missingrecipientpolicy 4 sourcespamfilter2optin spam sourcespamfilter1optin spam

tcp_intranet-daemon

any thing wrong here?>

Jerry_Goconnect at 2007-7-7 2:43:11 >

OK, I post current mapping file here.

I used backup mapping before, same result, strange

! MTA mappings file

! for access control and other table lookups

! modify this table INTERNAL_IP

! need to recompile config and restart MTA

! imsimat cnbuild

! imsimat restart

!

PORT_ACCESS

*|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E

* $YEXTERNAL

!

!

INTERNAL_IP

$(210.50.199.158/24) $Y

127.0.0.1 $Y

! $(218.242.216.7/32) $Y

! Dialup/ADSL access

! $(58.178.0.0/16) $Y

! $(210.50.0.0/16) $Y

* $N

ORIG_SEND_ACCESS

tcp_local|*|tcp_local|* $N$D30|Relaying$ not$ allowed

tcp_*|*|native|* $N

tcp_*|*|hold|* $N

tcp_*|*|pipe|* $N

tcp_*|*|ims-ms|* $N

!

! Block "external" submissions of explicitly source-routed "internal" addresses

!

tcp_local|*|tcp_intranet|@*:*.*$N$D30|Explicit$ routing$ not$ allowed

tcp_local|*|tcp_intranet|*$%*@*$N$D30|Explicit$ routing$ not$ allowed

tcp_local|*|tcp_intranet|*.*!*@* $N$D30|Explicit$ routing$ not$ allowed

tcp_local|*|tcp_intranet|"*@*"@* $N$D30|Explicit$ routing$ not$ allowed

SEND_ACCESS

tcp_*|*|*|*@[127.*] $X5.1.2|$NBad$ destination$ system

tcp_*|*|*|*@localhost.* $X5.1.2|$NBad$ destination$ system

tcp_*|*|*|*@example.com $X5.1.2|$NBad$ destination$ system

tcp_*|*|*|*@example.net $X5.1.2|$NBad$ destination$ system

tcp_*|*|*|*@example.org $X5.1.2|$NBad$ destination$ system

tcp_*|*|*|*@*.test $X5.1.2|$NBad$ destination$ system

tcp_*|*|*|*@*.example $X5.1.2|$NBad$ destination$ system

tcp_*|*|*|*@*.invalid $X5.1.2|$NBad$ destination$ system

tcp_*|*|*|*@*.localhost $X5.1.2|$NBad$ destination$ system

<IMTA_TABLE:mappings.locale

I modified PORT_ACCESS INTERNAL_IP FRIEND_IP, now all resume back. still no work.

maybe the patch problem?>

Jerry_Goconnect at 2007-7-7 2:43:11 >

yes, I always do

imsimta cnbuild

imsimta restart

Killing Dispatcher : 2892

Dispatcher startup requested

Job Controller shutdown requested

Job Controller startup requested

# ../../sbin/imsimta test -mapping

Enter table name: INTERNAL_IP

Input string: 210.50.199.168

Output string:

Output flags: [0, 'Y' (89)]

Input string: 127.0.0.1

Output string:

Output flags: [0, 'Y' (89)]

Input string: 202.67.64.1

Output string:

Output flags: [0, 'N' (78)]

see, testing fine.

Now I use outlook send mail to hotmail from210.50.199.168, server response 550 5.7.1 Relaying not allowed.

# more mail.log_current

12-Oct-2006 14:56:51.79 tcp_localJ 0 jerry.chen@goconnect.com.au rfc822; jchenmelb@hotmail.com 550 5.7.1 Relaying not allowed: jchenmelb@hotmail.com

It is clear 210.50.199.168 was not recognized as internal IP, msg went throught tcp_local channel.

Is it possible T58 patch introduced new bug?

Jerry_Goconnect at 2007-7-7 2:43:11 >

Thanks Shane and Jay

Finally get it works, guest what? reinstalled Messaging server. then it work as normal.

mapping file as:

-

PORT_ACCESS

*|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E

*|*|*|*|* $C$|IPRIMUS_IP;$3|$Y$E

* $YEXTERNAL

INTERNAL_IP

$(210.50.199.158/32) $Y

127.0.0.1 $Y

* $N

IPRIMUS_IP

$(210.50.199.168/32) $Y

* $N

ORIG_SEND_ACCESS

tcp_local|*|tcp_local|* $N$D30|Relaying$ not$ allowed

tcp_*|*|native|* $N

tcp_*|*|hold|* $N

tcp_*|*|pipe|* $N

tcp_*|*|ims-ms|* $N

.......

imta.cnf file as

! tcp_intranet

! Do mapping lookup for internal IP addresses

[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

! Do mapping lookup for iPrimus IP range, non-internal IP addresses

[]$E$R${IPRIMUS_IP,$L}$U%[$L]@tcp_iprimus-daemon

!

........

! tcp_intranet

tcp_intranet smtp mx single_sys subdirs 20 dequeue_removeroute maxjobs 7 pool SMTP_POOL maytlsserver allowswitchchannel saslswitchchannel tcp_auth missingrecipientpolicy 4

tcp_intranet-daemon

!

! tcp_iprimus

tcp_iprimus smtp mx single_sys subdirs 20 dequeue_removeroute maxjobs 7 pool SMTP_POOL mustsaslserver allowswitchchannel missingrecipientpolicy 4

tcp_iprimus-daemon

!

.......

-

Now msg enqueu/dequeu in tcp_local , tcp_iprimus, tcp_intranet by IPaddress, and do auth as well.

Jerry_Goconnect at 2007-7-7 2:43:11 >

I'm glad you have it working, now.

A quick examination of your mappings shows you are vulnerable to the "percent hack" that can allow people to use your server as an open relay.

You can add the following lines to the ORIG_SEND_ACCESS table to prevent that. This is now standard for 6.2:

! Block "external" submissions of explicitly source-routed "internal" addresses!

tcp_local|*|tcp_intranet|@*:*.*$N$D30|Explicit$ routing$ not$ allowed

tcp_local|*|tcp_intranet|*$%*@*$N$D30|Explicit$ routing$ not$ allowed

tcp_local|*|tcp_intranet|*.*!*@* $N$D30|Explicit$ routing$ not$ allowed

tcp_local|*|tcp_intranet|"*@*"@* $N$D30|Explicit$ routing$ not$ allowed

jay_plesseta at 2007-7-21 15:27:31 >