(it's a bit annoying that your mail client removes all threading
information. can you get that fixed?)
On Wed, 2004-09-22 at 16:46 +0100, Jon Kyme wrote:
> David Woodhouse <dwmw2@???> wrote:
> >You have no idea how many addresses 'dwmw2@???' is forwarded
> >to.
>
> Indeed, but this has very little to do with what I said.
how so?
> The post I responded to (it does seem a long time ago)
> was about RFC2505.
yes. let's repeat the relevant excerpt, since the thread is broken:
The most common case of such legitimate "MAIL From: <>" is to one
recipient, i.e. an error message returned to one single individual.
Since spammers have used "MAIL From: <>" to send to many recipients,
it is tempting to either reject such mail completely or to reject all
but the first recipient. However, there are legitimate causes for an
error mail to go to multiple recipients, e.g. a list with several
list owners, all located at the same remote site, and thus the MTA
MUST NOT refuse "MAIL From: <>" even in this case.
> The nub is:
> I don't believe there's any sound argument for accepting messages with the
> null sender but with recipients which were never in the return-path of a
> previous message,
not in the normal case, but yes, there's a sound argument for it. the
example scenario in RFC 2505 is:
alice and bob at yourdomain.bv are two of the list owners of
fidgeters@???. messages from that list are sent with a return-
path of fidgeters-owner@???. bounce messages are received at that
address, and forwarded to the individual owners. your server will be
seeing
MAIL FROM:<>
RCPT TO:<alice@???>
RCPT TO:<bob@???>
and it MUST accept the bounce and pass it on to your users. note that
this can happen even if alice _never_ sent a message via your server.
> nor any good reason why I should accept multiple
> recipients for a message with a null sender. These requirements would seem
> to put the convenience of third-parties over and above my needs.
see above. of course, if you _know_ that none of your users are mailing
list administrators on remote domains, you may wish to restrict what you
accept. this is similar to blocking all Korean traffic if you know
you'll never be entering Korean IP-space.
you can go for middle ground, though. refer to David Woodhouse' RPR
scheme:
http://www.infradead.org/rpr.html
if this is deployed, you should make sure your users know about it, and
understand that they need to specify a different address for mailing
list administration tasks. if you accept +suffix to be added to your
addresses, you may want to turn off RPR for those, and then Alice can
use alice+admin@??? as her administrator address.
> If you know of any such requirements in the mail RFCs
> (other than 2505 which I believe contradicted by 2821,
> and by much *current* practice)
what's the contradiction with 2821?
--
Kjetil T.
