up vote 0 down vote favorite
share [g+] share [fb]

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

000.000.000.000:1025 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!

Thanks!

link|improve this question
42% accept rate
Is it possible that their Unica system is simply unaware of your use of a non-standard port? BTW, you can safely remove the "000.000.000.000:" part from that config. – xyz Jul 15 '09 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 '09 at 2:42
feedback

3 Answers

up vote 1 down vote accepted

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.

e.g.

debug_peer_list=UNICA.SERVER.IP.ADDRESS
debug_peer_level=2

(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)

link|improve this answer
Great, thanks Craig, I'll give that a try and see what I find! – Christian Jul 15 '09 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. – Craig Sanders Jul 15 '09 at 4:26
Will do, thanks! – Christian Jul 15 '09 at 4:57
what was the problem in the end? – Craig Sanders Aug 11 '09 at 8:40
feedback
up vote 0 down vote

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.

/etc/postfix/main.cf:
sender_dependent_relayhost_maps = /etc/postfix/my_special_client

/etc/postfix/my_special_client:
@example.com  127.0.0.1:1025

# postmap /etc/postfix/my_special_client
# postfix stop && postfix start
link|improve this answer
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 '09 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 '09 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 '09 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 '09 at 5:06
feedback
up vote 0 down vote

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
link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

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