Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Previously I asked Who (which process) is calling curl? and I got very good answers (this answer in particular) which basically replace the curl binary with a shell script that logs each call to curl and then calls the renamed curl and passes the parameters along.

Now I am again in a similar situation, I know if someone is using smtp, but I don't know which process it is? I know that I use it in a cron job but I (by the alerts I receive from my firewall) some other times smtp tries to connect to the internet (google smtp servers if I am not mistaken).

How can I find out who/which process is using smtp?

share|improve this question

I don't know if it works on MacOS, but on linux you can do:

$ sudo netstat -ntop

and get output like:

tcp        0      0       ESTABLISHED 184/firefox    off (0.00/0/0)

The key part is the 184/firefox -- this is the PID and process name, respectively.

The trick would be catching this in action. If it happens regularly, you could run the command above in a loop and grep for the port you want to trap. Otherwise there may be some wizardry you can do with your firewall, but that's beyond my knowledge.

share|improve this answer
I believe port usage must stay for 60 seconds before a port number can be recycled (ex. the 'outbound' port form the process that connects to smtp port 25), so assuming it still shows up for 60 seconds in netstat, you would need at the very minimum every minute. – Adam Tuliper - MSFT Feb 10 '12 at 5:52
@Adam Tuliper: If every port existed for 60 seconds it would not be possible to get anything like the volume of traffic through a server than most handle. – symcbean Feb 10 '12 at 9:09
Did you actually research before posting that? :) it's true they remain in time_wait state. However don't confuse incoming port sharing. This is a known issue on high perf systems that a little searching will show plenty of people running into this. – Adam Tuliper - MSFT Feb 10 '12 at 16:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.