Re: [exim] Blocking error on bad transport..?

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] Blocking error on bad transport..?
Rob Munsch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So here's something funny.
>
> - -----
> Message 1GFdaj-00087w-00 has been frozen.
> The sender is <root@???>.
>
> The following address(es) have yet to be delivered:
> italerts@??? <root@???>:
> error in router: unknown routing option or transport name "philagrafika.org"
> - -----
>
> What on earth does that last unknown name have to do with mail from root
> to italerts?!
>
> Someone went and made some bad changes to the exim config, stopping up
> the entire system. Everything's frozen, filled with stuff like this;
> hundreds of 'em. Nothing's come out of that box in a week (not a major
> mailsystem; running an old exim for some reporting and suchlike, as you
> have likely guessed by the addresses involved).
>
> Still, two questions:
>
> 1) philagrafika is one of the domains we manage. Someone thought it
> needed to be there as the site is hosted on that box, i guess. Why
> doesn't it know about this domain, how is it "unknown?" There are 3
> other domains listed before that one that it likes just fine. How do i
> introduce them -.-
>
> 2) why the HONK does mail from A to B all come to a crashing halt
> because it doesn't know what W is?!
>
> tia,
>

All of this looks suspiciously like a single colon ":" or octothorpe "#" has
been omitted.

- a router or transport's first line, its name or label, must be terminated with
a colon, ELSE it may be seen as a continuation of a previous sibling, pure
garbage, or something half-way interpretable. None of these are good.

- a hostlist must have a colon (or other specifically-substituted character)
between each entry and the next. ELSE confusion.

- a comment line must start with an octothorpe, ELSE either confusion or an
attempt to parse the text as something not intended.

Exim will spot the really obvious, and even most of the quite obscure errors
when it is started/restarted, tell you what it thinks the problem is, and cite
the offending configure file line number. You may not see these unless you are
either perusing the ~/exim/paniclog OR using a shell command directly to
start/restart/reload the service over ssh.

....which is where you may want to begin w/r troubleshooting if ou have not
already done so..

if neither stderr/stdio or ~/paniclog is showing an error, then your error is a
very subtle one indeed. Something Exim would do if it could, even if it is not
what you wanted.

To give an example - I once left-out a line terminator "\" .. which had the
effect of Exim complaining NOT, but creating a Maildir structure with the rather
long and odd name of -

would you believe the entire SQL query clause that had been mean to *find* the
user's Maildir path, not *become* it.

;-)

But it then stored messages there and no mail was lost.. so...

Never forget that a computer is nothing more than a high-speed idiot.

Bill