From: mouss (no email)
Date: Mon Apr 16 2007 - 10:38:23 EDT

  • Next message: mouss: "Re: Default value of unknown_address_reject_code"

    Черкендов Александр Армаисович wrote:
    > ----- Original Message -----
    > From: "mouss" <>
    > Cc: <>
    > Sent: Monday, April 16, 2007 3:58 PM
    > Subject: Re: Empty MAIL FROM
    >> Mark Martinec wrote:
    >>>> you must accept <>, but you can use reject_multi_recipient_bounce in
    >>>> restrictions, for example in smtpd_client_restrictions
    >>> You may, but the use of a null return path is legitimate
    >>> for multi-recipient messages too.
    >>> RFC 3461:
    >>> When attempting to relay a message to an SMTP server that does
    >>> not support this extension, and if NOTIFY=NEVER was specified for
    >>> some recipients of that message, a conforming SMTP client MAY
    >>> relay the message for those recipients in a separate SMTP
    >>> transaction, using an empty reverse-path in the MAIL command.
    >>> This will prevent DSNs from being issued for those recipients by
    >>> MTAs that conform to [1].
    >> I remember you (Mark) sent some "false positives" a long time ago.
    >> another case is a bounce that is subject to alias expansion. rare, but
    >> could happen.
    >> anyway, if the check is done in smtpd_client_restrictions, then that
    >> should only result in the message being sent multiple times, once to
    >> each recipient. this is bad, but still acceptable. aa real problem
    >> occurs if the check is done in data stage.
    > is it wrong to check reject_multi_recipient_bounce in smtpd_client_restrictions?

    the first thing is to check your logs and see if it blocks spam. I doubt
    it. most spam comes with a forged sender, not an empty one.

    so, I've never seen it block spam, but it has been reported to block
    legitmate mail. and from a standard perspective, nothing prohibits a
    multi-recipient mail with a null sender.

  • Next message: mouss: "Re: Default value of unknown_address_reject_code"

    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs

    Powered By FreeBSD   Powered By FreeBSD