Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: domain alias + reject_unverified_recipient

  1. #11
    vipin65 is offline Member
    Join Date
    Jul 2010
    Posts
    11
    Rep Power
    4

    Default

    Changeing 450 to 250 may create problem because server start accepting mail from unverfied recipent from other mail servers and start fluinding with unwanted spam mail. If start fluinding it become very diffcult to menage on production server we have to disconnect server from public ip.
    Have you tried this with live server ( MX record active ) ?

  2. #12
    MajorTermi is offline New Member
    Join Date
    Mar 2011
    Posts
    3
    Rep Power
    4

    Default Experience with Exim

    Quote Originally Posted by vipin65 View Post
    Have you tried this with live server ( MX record active ) ?
    I have not tried this for Zimbra yet, as my Zimbra test setup is on a LAN server. However, I am using a similar setup on our current internet mail system, which is using the Exim MTA, not the Postfix MTA.

    I configured the MTA on our primary and secondary MX to check recipient addresses using a mechanism similar to the mechanism used by the reject_unverified_recipient option. In Exim this is called "recipient callout verification". I set the option in a way, that the server will accept an e-mail, if it cannot verify the recipient address because of a temporary problem. Such a temporary problem might exist, if the the MTA on the secondary MX receives an e-mail and the primary MX is down. This setup is describes in more detail in a blog article.

    I just checked the queues of both our primary and secondary MX and I could not find a single bounce message caused by an e-mail accepted for an invalid address. I am using this setup now for more than two years and did not experience any problems with it during this time.

    For Exim I configured a maximum delay of 10 seconds, thus if the check does not finally succeed or fail within this time, the message is accepted.

    It might be a good idea to fine tune the address_verify_poll_delay and address_verify_poll_count options to get optimal results with Postfix.

  3. #13
    vipin65 is offline Member
    Join Date
    Jul 2010
    Posts
    11
    Rep Power
    4

    Default

    OK I will read blog and try to understand what Exim done.
    Secondelly there is one more problem when mail reject with 450 error we tried to send mail from clinent ( outlook experess) every hour interval hole day but it not succesed.
    I think some server don't allow address verification so mail rejects.

  4. #14
    MajorTermi is offline New Member
    Join Date
    Mar 2011
    Posts
    3
    Rep Power
    4

    Default

    Quote Originally Posted by vipin65 View Post
    Secondelly there is one more problem when mail reject with 450 error we tried to send mail from clinent ( outlook experess) every hour interval hole day but it not succesed.
    I think some server don't allow address verification so mail rejects.
    This is interesting, because I did not experience this problem, even when I used an e-mail address that I knew would fail. When sending the message from an authenticated client, the server would still accept the message and then generate a mail delivery notification in the mailbox of the sending user.

    I think this might be related to the order of the options in the smtpd_recipient_restrictions option. I used the following order:
    Code:
    smtpd_recipient_restrictions = reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_invalid_hostname, reject_non_fqdn_sender, reject_unverified_recipient, permit
    I guess the server accepts mails for invalid recipient addresses but authenticated connections, because the permit_sasl_authenticated option is listed before the reject_unverified_recipient option.

    My postfix_recipient_restrictions.cf (which is used to generate the smtpd_recipient_restrictions option) looks like this:
    Code:
    %%contains VAR:zimbraServiceEnabled cbpolicyd, check_policy_service inet:127.0.0.1:10031%%
    reject_non_fqdn_recipient
    permit_sasl_authenticated
    permit_mynetworks
    reject_unauth_destination
    reject_unlisted_recipient
    %%contains VAR:zimbraMtaRestriction reject_invalid_hostname%%
    %%contains VAR:zimbraMtaRestriction reject_non_fqdn_hostname%%
    %%contains VAR:zimbraMtaRestriction reject_non_fqdn_sender%%
    %%contains VAR:zimbraMtaRestriction reject_unknown_client%%
    %%contains VAR:zimbraMtaRestriction reject_unknown_hostname%%
    %%contains VAR:zimbraMtaRestriction reject_unknown_sender_domain%%
    reject_unverified_recipient
    %%explode reject_rbl_client VAR:zimbraMtaRestrictionRBLs%%
    %%contains VAR:zimbraMtaRestriction check_policy_service unix:private/policy%%
    permit
    After reading the Postfix documentation more carefully, I think I now understand the address_verify_poll_count and address_verify_poll_delay options better. By default, Postfix uses the following values for this Options (in ZCS 7.0):
    Code:
    address_verify_poll_count = ${stress?1}${stress:3}
    address_verify_poll_delay = 3s
    These settings cause a problem, when the server is under heavy load, because the server will send the status code set in unverified_sender_defer_code, if the address being checked is not in the cache yet.

    I think, that even under stress, the server should check at least twice, thus the first query can trigger the verification process and the second can get the result. I would use something like
    Code:
    address_verify_poll_count = ${stress?2}${stress:3}
    address_verify_poll_delay = 5s
    These values will have the following effect:

    If the address is in the cache (either as valid or invalid), the check will succeed or fail immediately. If the address is not in the cache, the verification process will start and the client connected to the server will experience a five second delay.

    If the verification process has finished by then, the check will succeed or fail. If the veritification process has not finished yet but the server is under heavy load, the verificiation process will either fail (unverified_sender_defer_code set to 450) or succeed (unverified_sender_defer_code set to 250).

    If the server is not under heavy load, the client will experience an additional five seconds delay. If the verification process has finished by then, the check will succeed or fail. If the veritification process has not finished yet, the verificiation process will either fail (unverified_sender_defer_code set to 450) or succeed (unverified_sender_defer_code set to 250).

    With these settings, under normal conditions there is a very high chance that the check will have finished (because ten seconds are plenty of time for a check like that). Under heavy load, there is still a good chance, that the check will have finished (five seconds are enough in most cases).

    Whether you set unverified_sender_defer_code to 450 (default) or 250 depends on which situation you want to avoid:

    When setting it to 450, you might experience a situation, where the client is defered because the address could not be verified (although this seems to be no problem with authenticated clients as described above). When setting it to 250, you might generate a small number of spam backscatter, when the address verification is defered. From my experience, this is not a problem, because it rarely happens (as described in my previous post).

Page 2 of 2 FirstFirst 12

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Enable Login on Prexisting Alias Domain - How?
    By LMStone in forum Administrators
    Replies: 0
    Last Post: 03-06-2010, 08:50 AM
  2. Domain Alias and sender address
    By mederyf in forum Administrators
    Replies: 1
    Last Post: 09-04-2009, 09:24 AM
  3. Replies: 7
    Last Post: 04-27-2009, 02:49 AM
  4. Replies: 20
    Last Post: 03-18-2008, 05:37 AM
  5. Domain Alias / User Alias problem after upgrading.
    By Bingo in forum Administrators
    Replies: 1
    Last Post: 04-20-2007, 03:39 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •