We have some clients that send mail through our mail server. To batch send the mail, we have all mail on specific port (in this case 1025) forwarded to an accept script which saves the details in MySQL for batch processing. When I test this, it works perfectly, when the client tests, it works perfectly, however, when they send out from their Unica system, it looks like the mail goes straight past the script and into the mail stream. Is this possible?

Here are the lines from master.cf inet n      -       -       -       0       smtpd
        -o mynetworks=hash:/etc/postfix/injector/networks
        -o content_filter=clientid:
        -o syslog_name=clientid
        -o smtpd_timeout=1800s

clientid  unix   -       n       n       -       0       pipe
        flags=q user=filter argv=/var/injector/inject.php clntid

Any help would be much appreciated!


  • Is it possible that their Unica system is simply unaware of your use of a non-standard port? BTW, you can safely remove the "" part from that config.
    – xyz
    Jul 15, 2009 at 2:23
  • Well, this was my argument, but it is definitely sending through that port. It would appear that at some stage between the mail coming in and getting to the script, it goes elsewhere (i can see it in the logs). The 000 is the server's IP address, I dont need it there?
    – Christian
    Jul 15, 2009 at 2:42

3 Answers 3


to be able to diagnose the problem, you first need to start gathering more data. you can use the debug_peer_level and debug_peer_list options in /etc/postfix/main.cf.



(increase the debug level even further if that doesn't provide enough info)

once you've got that data, you'll be able to tell for sure whether the mail from the unica system is actually going to your custom filter or not (and it sounds like it isn't)

  • Great, thanks Craig, I'll give that a try and see what I find!
    – Christian
    Jul 15, 2009 at 3:48
  • and remember to turn off the debug logging when you no longer need it - it's extra load on the system and bloats out your log files.
    – cas
    Jul 15, 2009 at 4:26
  • what was the problem in the end?
    – cas
    Aug 11, 2009 at 8:40

SMTP goes through port 25 (thats a standard), so when your client sends through the Unica system, its sending to that port. On your side, the smtpd process listening on port 25 knows nothing about the inject.php script.

Your client must send through a system that is aware of your use of a non-standard port, be that a MTA (SMTP server), or a plain mail client. Or you have to redesign your setup.

Yes, you can remove the address (see man 5 master).

To clarify a bit, since we don't fully see your config, maybe you can get what you want (untested). If your client, or whatever, doesn't send to your port 1025, then aparently you can route his mail based on the sender address or domain.

sender_dependent_relayhost_maps = /etc/postfix/my_special_client


# postmap /etc/postfix/my_special_client
# postfix stop && postfix start
  • As stated, Unica is definitely sending through Port 25.I am just wondering if there is any way that emails could come in the right port (1025) but not make it to the script?
    – Christian
    Jul 15, 2009 at 3:12
  • I'm not sure we understand each other. :) Your server forwards mail to the script only if the mail arrives to port 1025, right? Then the other side (the client, the unica, whatever) MUST send to your server's port 1025. BTW, you said you've tested it. How?
    – xyz
    Jul 15, 2009 at 4:40
  • Yep, what I am saying is that it is sending to port 1025. I can send mail to it fine using the outgoing smtp port 1025 and the server address. So can the client, just not through Unica. It used to work before we made some system changes thats how I know they have it set up properly.
    – Christian
    Jul 15, 2009 at 4:56
  • If what's sugested doesn't solve your problem, then consider posting the output of 'postconf -n', maybe with private info edited. It would help to understand what might have gone wrong.
    – xyz
    Jul 15, 2009 at 5:06

For really detailed debugging, I'll sometimes do a tcpdump and pull that back into ethereal to examine the exact SMTP session that took place.

tcpdump -i any -s 1500 -w /tmp/some-file.dump host ip.of.your.client

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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