Mark Tippetts <[EMAIL PROTECTED]> writes:
> Sendmail is NOT the problem. Its presence is creating conditions where
> the problem manifests, but it's not to blame.
I beg to differ. The problem is created by sendmail's willingness to
treat the username portion of an e-mail address as specifying a non-local
destination. This is contrary to current mail RFCs and is useful only for
very specific historical addressing syntaxes that practically no one uses
any more, and definitely not on the open Internet. It is perfectly
reasonable for qmail to assume that hosts will treat e-mail addresses
ending with @<local-domain> as local.
If you turn off sendmail's support for UUCP bang-path addressing, the
entire problem goes away.
> The problem is qmail relaying this message from an untrusted host.
No, you've explicitly configured qmail to do that by telling it to pass
off local mail deliveries to another server. Certainly if you turn off
that relaying the problem will also go away, but I assume that this is
integral to your mail system design.
> Even if I did turn off UUCP rewriting for sendmail, the underlying
> problem remains: qmail is acting as an open relay for messages with no
> @domain specified.
No, it's not. It's acting as a specific relay for local deliveries, just
like you've presumably configured it to be. It is in no way an open relay
problem for mail servers to accept mail addressed to local users.
Those messages are invalid SMTP messages, since the RCPT TO envelope is
not a mailbox. How a specific SMTP server chooses to deal with such
messages is therefore undefined. qmail accepts them and treats them as
local, probably in an attempt to partially deal with the problems caused
by braindead user MUAs that try to talk broken SMTP that happens to be
accepted by sendmail.
> We don't live in an SMTP-only, qmail-only universe. (yet :)
The fact that you don't live in an SMTP-only universe is precisely the
problem.
You are mixing multiple different addressing syntaxes within your mail
network. Different portions of your mail network are interpreting the
same address in different fashions.
This is a bug. It will cause you many other problems besides this one.
You should fix it. Fixing it by mandating an SMTP universe is perfectly
reasonable, works, and is the least likely to cause further surprises down
the road.
> The problem can be redefined as, "qmail appends envnoathost to ANY rcpt
> address without a domain". This works too:
Yes, because it's a variation of the same UUCP addressing syntax as your
previous example.
If you absolutely cannot live without UUCP addresses for some odd reason,
you can force qmail to bounce all unqualified addresses by putting
something like "unqualified.invalid" in control/envnoathost. This will
probably not have any negative effects, given that qmail-inject will
canonicalize local e-mail addresses before passing them to qmail-queue
anyway.
But I stand by my statement that this is papering over the bug, not fixing
it. You need to decide what addressing convention your e-mail network
uses and enforce it uniformly, or you're asking for more problems down the
road.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
