Re: Yow, Madduck!
On Fri, Jan 11, 2002 at 12:02:12AM -0500, Brenda J. Butler wrote:
| Well, I had two drivers in the ROUTERS section, and smarthost
| was second with a route_list whose "match-this-pattern" was
| *. I moved it above lookuphost and it seems to work. Let's
| see if it keeps working and doesn't break anything else (not
| that I think exim tends to break, but I tend to break things
| when I mess with them).
|
| I had put it after lookuphost because I misunderstood the part
| in the exim manual that said "A router like this should be
| the last one in the configuration file, since it will route any
| domain whatsoever".
What that meants was if you wanted to handle certain hosts specially.
For example, say you want mail destined for madduck.net to be routed
to a certain handler and other mail to be handled by the smarthost.
You would put a router in that handles madduck.net first, then the "*"
(everything not yet handled) router. You have 2 routers (lookuphost
and smarthost) that both handle everything. This means that the first
actually gets everything and the other is pointless.
| So that's the first part fixed: now I'm using my isp
| as a smarthost (and the isp even seems to accept it! Great!)
|
| The next part is to try to make the message come from something
| that can be resolved.
Your ISP can resolve you (as much as it really wants to), and others
can resolve it.
| Here are the Received headers from my email to myself (I sent it to
| an external mail re-director).
Ok, let's work our way through them, from beginning to end (the first
one is last in the list).
| Received: from bjb by seal with local (Exim 3.12 #1 (Debian))
| id 16OtJ9-0004QT-00; Thu, 10 Jan 2002 23:28:47 -0500
The first thing that happened is exim was run by the user 'bjb' and
given a message. The message arrived via a pipe (standard practice
for mailers and scripts) instead of from a socket.
| Received: from seal (mail@port-15.ottawa4.achilles.net [209.151.2.114])
| by web30.achilles.net (8.9.3/8.9.3) with ESMTP id XAA21655
| for <me@remailer.address>; Thu, 10 Jan 2002 23:17:20 -0500
Nex the system web30.achilles.net received the message vis ESMTP from
a host who said it was 'seal' in the EHLO command, but whose IP is
209.151.2.114 which resolves to mail@port-15.ottawa4.achilles.net (I
didn't think the "@" was legal in a hostname though, perhaps that is
just something the MTA sticks in the header). Additionally that MTA
records that the envelope recipient (in the RCPT TO: command) is
"me@remailer.address".
The message is now out of your system and has been accepted by the
next system (your ISP's smarthost). You have no control over anything
else that happens to it.
| Received: from web30.achilles.net (web30.achilles.net [209.151.0.6])
| by machine.remailer.address (Build 101 8.9.3/NT-8.9.3) with ESMTP id XAA09994
| for <me@remailer.address>; Thu, 10 Jan 2002 23:31:03 -0500
Next web30.achilles.net (whose IP reverse-lookup's to its name) handed
the message off to "machine.remailer.address". It appears that that
is a system running on Windows NT (based on that build number).
| Received: from unknown (HELO machine.remailer.address) (206.99.235.25)
| by samaria.achilles.net with SMTP; 11 Jan 2002 04:30:36 -0000
I'd say that your ISP has its 'doze machine misconfigured because it
claims it is "machine.remailer.address" but that name doesn't exist.
The IP of the machine is 206.99.235.25. That system handed the
message to samaria.achilles.net.
| Received: (qmail 21575 invoked from network); 11 Jan 2002 04:30:36 -0000
qmail got the message next. Pretty sparse data here. I guess one
would need to be familiar with qmail's operation to know what "invoked
from network" means. Still, it doesn't say what machine or anything.
| Received: from pop1.achilles.net
| by localhost with POP3 (fetchmail-5.3.3)
| for bjb@localhost (single-drop); Thu, 10 Jan 2002 23:31:48 -0500 (EST)
The next thing that is recorded as happening is that
pop1.achillies.net gives the message to "localhost". Fetchmail
grabbed the message via POP3 and delivers it to bjb@localhost.
Presumably "localhost" here is your own machine.
| Received: from localhost [127.0.0.1] (bjb)
| by seal with esmtp (Exim 3.12 #1 (Debian))
| id 16OtM4-0004Rn-00; Thu, 10 Jan 2002 23:31:48 -0500
| Delivered-To: bjb@achilles.net
The last thing that happend is fetchmail handed it to exim via SMTP (I
suggest changing fetchmail to use a pipe instead). Your machine
received it and delivered it to you.
| So machine.remailer.address thinks it is getting the message from
| web30.achilles.net which can be resolved: should this be sufficient?
Even before that, since web30.achilles.net accepted the message it is
sufficient.
| Or is the next Received header (Received: from unknown...) trying
| to tell me something about my exim.conf?
Nope, it is telling you that your ISP is (partially) messed up :-).
The purpose of the Received: headers are just to allow admins to track
down what happened to a message so that configs can be debugged. Each
system can be configured to put whatever it wants as a Received:
header, or nothing at all. It is recommended to include the info,
though, in case something goes wrong somewhere.
Now I'm curious as to what "me@remailer.address" really means -- there
is no domain "remailer.address" :
$ host machine.remailer.address
machine.remailer.address does not exist (Authoritative answer)
$ host remailer.address
remailer.address does not exist (Authoritative answer)
$ host 206.99.235.25
Nameserver not responding
206.99.235.25 PTR record not found, try again
I also can't find any name for that "machine.remailer.address" host.
Each of those systems that handled the message after yours must know
how to deliver to that address. Perhaps that is another sign of a
misconfigured MTA -- did you really send the message to
"me@remailer.address"?
-D
--
Microsoft encrypts your Windows NT password when stored on a Windows CE
device. But if you look carefully at their encryption algorithm, they
simply XOR the password with "susageP", Pegasus spelled backwards.
Pegasus is the code name of Windows CE. This is so pathetic it's
staggering.
http://www.cegadgets.com/artsusageP.htm
Reply to: