Re: [exim] a large number of domains fronted by Exim are ref…

Top Page
Delete this message
Reply to this message
Author: Matthew Byng-Maddick
Date:  
To: Exim User's Mailing List
Subject: Re: [exim] a large number of domains fronted by Exim are refusing bounces...
On Thu, Jun 30, 2005 at 05:14:51PM -0400, Greg A. Woods wrote:
> That's not acceptable in my world, nor is it acceptable to the SMTP
> protocol standard.

[...]
> However I've not been talking about the "author's way" here -- but
> rather a fundamental requirement written into the protocol standard.


I'm guessing that this would be similar to the fundamental requirement to
accept mail for postmaster and not check the content of the argument to HELO,
neither of which smail forces you to do properly (judging by various machines
in the weird.com domain).

Greg, many of us have been using SMTP for a very long time, and have a good
understanding of the reasons and the requirements of the RFCs. As you have
often said, it's important to look at site-local policy, it's also important
to look at current best-practice, and to read between the lines in other RFCs
than just STD0010.

In probably 7 or 8 years of managing a mail server, during which time the
landscape has changed significantly. I have, to the best of my knowledge,
never seen a legitimate null-return-path message that was sent to an address
derived from anywhere else than the incoming return-path of another message.

RFC2821, which you handily quoted elsewhere in this ridiculous thread,
helpfully says:
All other types of messages (i.e., any message which is not required
by a standards-track RFC to have a null reverse-path) SHOULD be sent
with with a valid, non-null reverse-path.

Which means, to anyone who understands English, that you have to have a
pretty good reason to emit null-reverse-path mail for any reason other
than the standards-track RFC (all of which, to my knowledge, are based on
reverse paths of incoming messages). Please could you either:
 a) give the very good reason that you have for having those
    non-standards-track messages with a null return-path
or
 b) cite a standards-track RFC which asks to emit a null return-path message
    to an address derived from somewhere otehr than the return-path on an
    incoming message.


If you can do this, then I will believe that your argument holds. As yet,
I've read nothing from you that makes it seem that what you have said so
far in this thread is anything but crazy rants. I know that you're more
intelligent than you're currently appearing, so please, apply some of your
rather better than currently apparent reading comprehension skills, and
when replying, answer the questions that have actually been posed, not the
ones that you want to answer.

Cheers

MBM

-- 
Matthew Byng-Maddick          <mbm@???>           http://colondot.net/
                      (Please use this address to reply)