help on filter mail sent with my msg server domain
Hi,
my environment is SunOne Messaging Server 5.2 sp2, on Solaris (sparc) 2.8.
I need help to solve the following problem: some mail user of the platform, for example "foo@mydomain.com" receive message with sender "foo@mydomain.com" and this message is sent by external mail server. All the mail user send email with authentication, I mean when they send an email, the email is dispatched on "tcp_auth" channel.
So I have tried to insert into the "mappings" file the filter
ORIG_SEND_ACCESS
....
tcp_local|*@mydomain.com|tcp_local|*@mydomain.com $Nnot$ allowed$
but this does not work, if I execute a SMTP session on my mail host
I can send an email and into the log file I see that the dispatcher channel is "tcp_local -> tcp_local".
Please could you tell me why the filter does not work fine?
thanks in advance
[882 byte] By [
m_mattau] at [2007-11-26 10:01:37]
# 1
I'm having some difficulty understanding what you're looking for, so I'll re-phrase what I think you asked for.
You say you have a user that gets mail addressed to him, but with him as a return address, and you want to stop it, is that right?
In fact, there is no sure-fire way to prevent the forging of a return address. Compare e-mail with a paper envelope. A person can put whatever return address on the envelope he wants, and you cannot prevent that. It's on the mail when it's sent.
You can reduce this, somewhat, but never prevent it. I use SpamAssassin to reduce spam, "mailfromdnsverify" this checks that the from is actually a valid domain.
# 2
Hi, maybe I was not so clear:
I have a user, with email address "name.surname@mydomain.com" that receive email from "name.surname@mydomain.com", I mean sender and destination address are the same, but the sender send the email from an external host. I think that the sender execute a SMTP session on my mail server and use:
MAIL FROM:name.surname@mydomain.com
and
RCPT TO: name.surname@mydomain.com
I have seen that into the log file the dispatcher channel is from tcp_local to tcp_local, and so I have tried to stop this using the filter described above into mapping file, but it does not work....
How I can do it? I already use "mailfromdnsverify" into the tcp_local definition. Thanks for your attention.
# 3
If your system allows "tcp-local" to "tcp-local", you have a very serious misconfiguration of your system. Normal, default installation will NOT allow this at all, unless the user is authenticating.
Check your mail.log_current and see if you see "EA" rather than the more normal "E".
If you do see "EA", that means that this sender has broken one of your passwords, and you may need to change some. A common problem is that the "store administrator" defaults to "admin", and many people don't use strong passwords for that "admin" user. I've been victim to that, too.
# 4
Hi,
If the address <uid>@mydomain.com is indeed within your organisation, the email won't be going out the tcp_local channel which is what you have specified. As Jay noted, by default any email from tcp_local to tcp_local is denied regardless (as this implies open relaying which is bad).
If you review the logs for the scenario you presented, namely an external host sent an email to an internal recipient and forged the envelope from address then you will probably see either tcp_intranet (if the server is relaying to an internal system) or ims-ms (if the account is hosted on the same system) as the destination channel.
So the rule you should actually be using is something like:
ORIG_SEND_ACCESS
tcp_local|*@mydomain.com|*|*@mydomain.com $NExternal$ delivery$ for$ mydomain.com$ not$ allowed$ without$ authentication
Regards,
Shane.
# 5
Hi,
thanks for suggestion, with the record suggested I have solved my problem.
Regarding dispatcher from tcp_local to tcp_local, it is because I have the messaging server installed on an application layer, and, on front end, 2 mta servers. So when the server receive an email from internet, it is dispatched from tcp_local to tcp_local and then on the internal channel.
Thanks a lot an Regards
# 6
I would consider this to be a serious mis-configuration of your system.
If you allow tcp_local to tcp_local, then what prevents anybody from sending mail through your system?
Your second layer should be mapped to tcp_intranet, and your external MTA should not allow relay between tcp_local and tcp_local. Period.
