On Mon, Apr 17, 2000 at 10:01:08PM -0400, Mark Tippetts wrote:
> Hey,
>
> Haven't found anything about this in the archives, I've tried playing with
> it to no avail.
This is, in fact, in the archives. The same thing has happened to me a
couple of times.
My newest qmail-box (that went production yesterday) is also already in
ORBS, but that's because ORBS now does it's relaying tests from our own
network, meaning it is in the qmail-smtpd.cdb file for tcpserver. I will
fix that shortly :)
> One of my mail servers was put in ORBS today. I can't use ORBS myself, but
> I value what they're doing, and I consider the problem that got me there a
> real one. The test we failed involves a header in the format "rcpt
> to:<foo!bar>". qmail-send grabs this address and appends the address in
> .../control/envnoathost, resulting in <[EMAIL PROTECTED]>. This is then
> delivered in the normal way, using MX records, to the primary hub for the
> lynxus.com domain, which runs sendmail. Sendmail does it's thing with the
> UUCP addressing, and I wind up in ORBS.
Yes. Sendmail is broken.
> This seems broken. Qmail should not treat mail as local JUST BECAUSE it has
> a rcpt header with no domain. I understand the value of being able to treat
Uhm. If the sender would have appended the domain you append by default,
the mail would have been delivered just as easily. The problem is that
sendmail processes the RCPT TO (which is prohibited by RFC821!) if this
message comes from a trusted host. And it should be able to trust your
qmail-host, since it _is_ in your local network..
> mail without a domain in the rcpt as local (a lot of scripts assume this
> will happen, and users expect it on some systems), IF that mail is actually
> invoking the MTA locally. But there should definitely be some distinction
> made between actual local mail and mail that simply has no domain specified.
> Maybe .../control/envnoathost should only be used if the mail originates
> from 127.0.0.1? Something.
That is not gonna solve anything, as per above.
> Anyhow, I'm hoping this isn't a bug report. I'd really like someone to tell
It is a bug report. It is a bug in sendmail, in that it allows you to
easily misconfigure it to perform brokenly (or may even come preinstalled
that way).
> me, "just do -this-, and rcpts without a domain will stop being treated as
> local." The man page for qmail-send says envnoathost will default to
> .../control/me, so I can't just remove the file. I've tried copying
> /dev/null into it; that doesn't work either. I don't want to put some bogus
> domain in there... doesn't seem like I should have to intentionally
> misconfigure my server to protect it from spammers.
>
> Any solutions, possible solutions, or statements of "you blithering idiot,
> just..." would be greatly appreciated.
Fix the UUCP and percenthack processing on your sendmail.
Note that Exim+Postfix (Exim as qmail in this story, Postfix as sendmail)
show the same broken behaviour. This doesn't mean anything about Exim
(apart from that it handled this situation as correctly as qmail would),
but it does say Postfix sucks.
Turning this around, putting Postfix on the outside, gives other broken
behaviour - even if Postfix is set up to be a secondary MX (which means it
may _never_ touch the RCPT TO:) it will reject mail with a % in is. Yes,
this is broken.
Greetz, Peter.
--
Peter van Dijk - student/sysadmin/ircoper/madly in love/pretending coder
|
| 'C makes it easy to shoot yourself in the foot;
| C++ makes it harder, but when you do it blows your whole leg off.'
| Bjarne Stroustrup, Inventor of C++
