Open groe opened 9 years ago
Hi,
All the missing symbols are from stuff generated using gperf by the build system. Can you check that gperf is installed on your system? then run make distclean
then make
I did install gperf and ran make clean
but I did not think of make distclean
. That fixed it, thanks a lot!
Incoming bounces are now correctly resolved to the original sender address before SRS translation. So if I connect to the server via SMTP and send to the SRS bounce address as RCPT-TO-adress the mail is accepted. However, when the bounce message is generated locally by the server itself, the address is not resolved (it seems like recipient_canonical_maps
are not applied when postfix generates the bounce message itself).
Sep 30 15:40:19 myserver postfix/virtual[22549]: 2BE2C54172C: to=<srs0=XXXX=YY=original=address@mydomain>, relay=virtual, delay=0.12, delays=0.07/0.01/0/0.05, dsn=5.1.1, status=bounced (unknown user: "srs0=XXXX=YY=original=address@mydomain")
Have you experienced this as well? Any tips on how one could enable delivery of bounce messages generated by the local mail server as well?
Again, thanks a lot for your help!
I'm afraid I cannot help you on that one, I've not been involved in complex postfix configurations for years now.
Maybe you can check your master.cf to see the actual workflow for bounces generated by the local mail server: do they go through a cleanup daemon? has that cleanup instance the expected recipient_canonical_maps
?
Thanks for your hints! After hours of verbose logging, debugging and drilling down the cause I finally got it to work.
Turns out the problem was not related to postfix but to pfix-srsd or libsrs2. Sporadically pfix-srsd would fail to translate a SRS address back to the original address with message "500 Hash invalid in SRS address."; this was happening very sporadically, so the only way I could reproduce it was to connect to pfix-srsd with telnet, translate a bunch of addresses, connect to the other pfix-srsd port with telnet and try to translate all addresses back. I noticed that sometimes just repeating the last request in telnet yielded different SRS addresses as responses - one would resolve successfully, the other one failed.
I fixed the problem for me by using a new secrets file. Previously I had a file with 100 lines, each with 92 characters (base64 encoded). When decoded, each line would be a md5 hash followed by " -" (i.e. space, space, minus; that propably came from how I generated these). E.g. one line in my secrets file was MWUwZjkwYjU3MmJkOGYwZjliN2I4MzAyOWJiNzJkMjU5YmQ1OTcwZjM3MWNlN2Q3MTIzZjMzMmZmZmJkZmQyOSAgLQo=
My new secrets file is only one line and that line is 16 random base64-encoded bytes (hope thats enough?).
Let me know if I can provide you with any additional information to fix the issue - or at least mention it somewhere in the docs, so others can find it as well. I think #9 had a similar problem as well.
Keep up the great work!
I am currently running pfix-srsd and it does the SRS forward translations perfectly. However, similar to #9, bounces are rejected ("unknown user"). The problem seems to be that
smtpd_recipient_restrictions
is not aware of the SRS bounce address and therefore rejects it.If I understand that correctly, using postlicyd.conf-srs would fix this, but I can't build it unfortunately...
I am running Ubuntu 12.04, the latest pfixtools 0.9, gcc 4.6.3, ld 2.22, libsrs2-1.0.18, libunbound-dev 1.4.16-1, libpcre3-8.12-4, libev4-4.11-1, libtokyocainet-1.4.37-6.1build1.
Any ideas?
I would appreciate any help!