Re: postfix as incoming relay to protect exchange server / recipient lookup
- Am 05.12.2010 20:40, schrieb DTNX/NGMX Postmaster:
> On 02/12/2010, at 23:08, Stan Hoeppner wrote:yes, thanks ... we did already.
>> 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;
>>> 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;
> 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.
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.