Mail clients don't use 113 (ident) or 25 (smtp) to check mail. They use things like 110 (pop3) or 143 (imap4).
But if you are permiting in all tcp and you still cannot get through with a client, then that sounds like a problem with the static translations. Try pushing your logging level up to 6 and seeing exactly what the log messages say.
If the problem were with receiving mail from outside systems, then according to Cisco, that can be caused by not having a working reverse DNS record for the IP. That explanation has never made sense to me -- the PIX doesn't do reverse DNS.
You are right; it is the pop3 for checking. Sorry, I mean we can not check or send email from within the inside. hmmmm, we are using dynmaic translation for normal users. Does it mean that we need to have static translations for all of them? That is weird.
What I believe that Walter means here it that to receive mail from an untrusted source (i.e. outside interface) to a trusted source (e.g inside interface) you will need to have a static translation and a relevant access-list entry.
mapped_address = public ip of your e-mail box real_address = the private IP of the same box
The access-list entry you have is generic. You should be much more specific when allowing access to your e-mail server.
access-list acl_grp permit tcp any host mapped_address eq 25
and so on allowing only the relevant protocols in to the box concerned from the hosts that you want.
Also DNS still could be an issue - NB I am not expert here. For outbound access does your e-mail box have valid DNS servers. Can you do an nslookup from this machine. If you can't work out the destination IP the e-mail won't go out onto the Internet.
Inbound access - does your machine do reverse DNS ? you can set this option I believe on a number of mail servers and mail filters. If you are receiving e-mail but your machine is trying to validate the sender, it may not accept the e-mail if it can't resolve in the other direction this dropping inbound e-mail.
After checked the monitor log, we found out that the pix denies the traffic from the ISP server to the dynamic translation IP (PAT). We still cannot fix this one yet. However, we find out there is another weird BIG problem with the pix. Will try to fix this one later.