Am 05.12.2010 20:40, schrieb DTNX/NGMX Postmaster:
On 02/12/2010, at 23:08, Stan Hoeppner wrote:
Martin Kellermann put forth on 12/2/2010 6:08 AM:
and there's a 5 sec. delay ... seems way too long to me for just
checking the recipient...!?
That delay should be no longer than what a typical delivery to the
Exchange server would be. Since no message is sent, it should be
shorter by quite a bit. I would guess the delay is within the Exchange
server, not Postfix, so you may need to do some sleuthing on the Exch
server to see what it causing the delay.
A testing tool like 'swaks' is great for testing RAV and other SMTP
transactions;
http://jetmore.org/john/code/swaks/
PS: should unverified_recipient_reject_code set to 450 or 550 ?
You should probably leave this at the defaults. As I understand it, the
default configuration will return a 5xx for "unknown user" and a 4xx if
the query fails, due to network, etc.
The default is '450' for both unknown users and transient errors, see;
http://www.postfix.org/postconf.5.html#unverified_recipient_reject_code
From the same page: "The unverified_recipient_reject_code parameter specifies the
numerical response code when an address is known to bounce (default: 450, change into 550
when you are confident that it is safe to do so)".
We also found it very handy to set up our 'notify_classes' parameter, so the
postmaster (or any other user you configure) gets a transcript of the SMTP
session when Postfix rejects mail. Note however that this adds load and can
generate a large volume of messages to the postmaster. It works for us at our
current volume, YMMV.
Lastly, you may want to set a value for 'unverified_recipient_reject_reason' if
you don't want to share the details of the backend server, such as hostname
and/or IP address, with the outside world.
yes, thanks ... we did already.
every parameter is well documented - and after i read the
postfix-manual-pages it's meanings
are easy to understand :-)
setup works now as expected and we started a test-run to see how
performance on exchange
side and how big the SMTP-overhead is...
thanks again for all your effords and contributions.
Cya,
Jona
