On Wed, 19 Mar 2003, Peter Samuel wrote:
> 
> Now I understand. I agree that qmail-remote's behaviour is
> inconvenient in this case. However I may have a work around for you.
> 
>        ...
> 
> So, try doing this:
> 
>     echo "[$(/sbin/e-smith/db configuration get ExternalIP)]" \
>       > /var/qmail/control/helohost
> 
> And then try sending some mail to the ISP in question. If it succeeds
> you'll need to add some logic to the ip-up event (or the ip-change
> event, I can never remember which) to expand your custom template for
> /var/qmail/control/helohost.
> 
> If it doesn't work, please let us know.

Please let us know if it does work too.

I've done some more research and this issue was raised on the qmail
list on Dec 22 1997.

    http://www.ornl.gov/cts/archives/mailing-lists/qmail/1997/12/msg00784.html

There wasn't a great deal of useful discussion (as far as we are
concerned) however one poster did quote from RFC 1123 "Requirements for
Internet Hosts -- Application and Support"

    ...

    5.2.5  HELO Command: RFC-821 Section 3.5

        The sender-SMTP MUST ensure that the <domain> parameter in a HELO
        command is a valid principal host domain name for the client host.
        As a result, the receiver-SMTP will not have to perform MX
        resolution on this name in order to validate the HELO parameter.

        The HELO receiver MAY verify that the HELO parameter really
        corresponds to the IP address of the sender.  However, the
        receiver MUST NOT refuse to accept a message, even if the sender's
        HELO command fails verification.

Now, I don't know if RFC 1123 can be treated as gospel, certainly RFCs
821 and 2821 don't seem to make this assertion.

The original poster had the last word and said

    "... In any case, since the error is occuring during the HELO, and
    not during the actual message delivery, there is no reason for qmail
    to associate the failure with a particular message, which should
    cause it to be treated as a temporary failure."

Please let us know if the method I suggested above succeeds or fails.

-- 
Regards
Peter
----------
Peter Samuel, Senior Systems Administrator  [EMAIL PROTECTED]
http://www.e-smith.org (development)        http://www.mitel.com (corporate)
Phone: +1 613 592 2122                      Fax: +1 613 592 1175
Mitel Networks, 350 Legget Dr, Ottawa, ON K2K 2W7 Canada

"If you kill all your unhappy customers, you'll only have happy ones left"


--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org

Reply via email to