Re: Sendmail question

From: Craig Green (freebsd_at_craigg.org)
Date: 02/14/05

  • Next message: Keith Nunn: "Cyrus imap TLS and SSL" 
    Date: Mon, 14 Feb 2005 11:47:43 -0500
To: Noah Davidson <NoahD@oopz.com>

    Noah Davidson wrote:

    >This is a backup mail server. The primary mail server is an Exchange 2003 server. So when mail is sent to invaliduser@bdomain.com then this server sends the mail to the exchange server that is responsible for handling the mail for domain.com. Since the user does not exist it bounces the mail.
    >

    The usual way of preventing bouncing is to have a list of valid users on
    the secondary MX as well as the primary. That way the secondary MX can
    reject mail for bad recipients, rather than being forced to accept
    everything, attempt a relay and bounce email for the bad rcpts.

    Naturally, there are a lot of instances where this is not possible. :-/

    To work around this problem, what we did was use a 'call-ahead' milter,
    specifically Snert's milter-ahead. See http://www.milter.info/. It's
    not in Ports, but it compiles easily enough from tarball and the author
    even includes a FreeBSD compatible startup script. If you're leery
    about using programs not in Ports, MIMEDefang is in Ports and while it
    does not do this by default, if you know Perl coding a call-ahead
    function for it would be easy enough to do.

    What the milter does is after getting a 'RCTP TO' command from the
    foreign SMTP server, it checks to see if a route exists for the
    recipient domain in the mailertable (i.e. if the mail server is acting
    as a gateway or relay for the recipient domain). If a route does exist,
    it initiates an SMTP connection to the indicated destination server and
    sends a HELO / MAIL FROM: <> / RCPT TO: sequence, with the RCPT TO being
    what the milter received from the foreign server. If the milter gets
    back a 'recipient okay' from the server in the mailertable, then it
    tells the foreign server 'recipient okay'. If the recipient is
    rejected, then the milter also rejects the recipient.

    In essence, it forwards on the response from the server in the
    mailertable to the foreign server--hence 'call ahead'.

    Milter-ahead includes a cache (with a configurable timeout) of
    previously-checked recipients so it doesn't have to query the server in
    the mailertable every time. Its behaviour when it can't reach the
    server in the mailertable is configurable; you can either have it give a
    4XX temporary error, or just accept the message. The latter is most
    appropriate for backup MXs and is what we use.

    Instead of bouncing a couple hundred thousand emails a day, we now
    reject them immediately at the border. This saves us from annoying a
    lot of people, generating double-bounces when the envelope sender is
    faked, cuts down on our bandwidth usage (since we reject after the RCPT
    TO, the email body is never sent), and saves our spam and virus scanning
    resources. It does increase the number of SMTP connects to the
    destination server, but from a bandwidth point of view, you can check a
    lot of email addresses in the bandwidth saved by rejecting a couple of
    viral emails instead of forwarding them on and having them bounce. All
    in all, it's a clear win for us.

    The only downside is that a reject response may be cached for an email
    address that later is activated and becomes valid. As you might guess
    this happens vanishingly rarely, but it has happened once or twice.
    Keeping the cache time to a day or two mitigates this (it defaults to
    one week(!)); with a one day cache, newly invalidated data will be held
    for an average of only 12 hours. If we do get a report, we simply flush
    the cache and all's well.

    Regards,

    Craig.
    ------

    >Then the root alias gets a copy of the bounced mail. Is there any way to prevent this from happening? This server should just queue the mail for the exchange server until the exchange server is available.
    >
    >Thanks
    >Noah Davidson
    >
    >_
    >

    _______________________________________________
    freebsd-isp@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-isp
    To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org"

  • Next message: Keith Nunn: "Cyrus imap TLS and SSL"

    Relevant Pages

    • Re: SBS 2003 New user does not appear in Public mail group.
      ... Configuration) and Recipient Update Services. ... In Exchange System Manager, expand Recipients, Recipient Policies. ... Exchange server settings page, please ensure input the correct server name ...
      (microsoft.public.windows.server.sbs)
    • Re: Outbound email tracking?
      ... if there were someone using your mail server... ... > attributed to this type of spam. ... > To Configure Recipient Filtering ... > When you enable recipient filtering (if you are using SMTP for incoming ...
      (microsoft.public.windows.server.sbs)
    • Re: Exchange Weird Issue
      ... Nope - it's only going to user b, she forwards it to the intended recipient. ... Emails are from different external users, ... Your server is open relaying emails. ... When you enable recipient filtering on the SMTP virtual server, ...
      (microsoft.public.windows.server.sbs)
    • RE: unable to send email to someone
      ... If the error code is 5.7.1 or 5.7.3 i have the following solution. ... Mail Transfer Protocol (SMTP) virtual server. ... the matching recipient policy might not exist. ...
      (microsoft.public.exchange2000.general)
    • RE: POP3 connector accounts and DNS
      ... recipients with the same e-mail domain causes NDR. ... If a local recipient with that e-mail address does not exist, ... Configure the SMTP virtual server in Exchange to send mail with unresolved ... recipients to the Internet service provider's mail server. ...
      (microsoft.public.windows.server.sbs)