Hey,

Haven't found anything about this in the archives, I've tried playing with
it to no avail.

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.

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
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.

Anyhow, I'm hoping this isn't a bug report.  I'd really like someone to tell
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.

Thanks,

        mark tippetts

Reply via email to