Hai Tony,
Could you save this message and then sent it as attachment back to me?
I want to have a closer look at the headers. (no need to send that copy
to the list)
On Sat, Dec 16, 2000 at 04:35:20PM -0500, A R wrote:
...
> fetchmail: analyzing Received line:
> Received: from murphy.debian.org ([216.234.231.6])
> by mtiwgwc24.worldnet.att.net
> (InterMail vM.4.01.03.10 201-229-121-110) with SMTP
> id
> <[EMAIL PROTECTED]>
> for <[EMAIL PROTECTED]>;
> Sat, 16 Dec 2000 21:11:36 +0000
> fetchmail: line rejected, mtiwgwc24.worldnet.att.net is not an alias of the
> mailserver
It has been some time since I set up my own fetchmail files, so it
takes me some time remembering all:( What is bothering us now is
that your pop host is not the same as the host on which the mail
is received by your ips, moreover this receiving host changes over
time (those mtiwgwc*.worldnet.att.net names). According to the docs
this shouldn't bite us in 'single-drop' mode, and here on my machine
that's right. But on your computer it fails, looks like you're run-
ning in 'multi-drop' mode. To check this out could you mail the
outcome of "fetchmail -V" run as tony? Somewhere to the end of its
output you are likely to find a line that is similar to:
" Single-drop mode: 1 local name(s) recognized."
If it says Single-drop, then your fetchmail isn't working like mine
(you are running potato? no woody aka unstable intermingled I hope)
If it says Multi-drop, then you'll have to look carefully at your
~/.fetchmailrc file; a single * could switch you into that mode.
Back to the aka line in multi-drop mode. I've done a lot of testing
this night and it looks like the aka hosts have to be spelled out, no
domain wildcarding or whatever, just plain listing them all. This
differs from the docs, so I wonder what I'm overlooking. In multi-drop
mode Fetchmail parses the headers to see to whom the mail is addressed,
per default it uses the "Recieved:"-lines. In those lines this
changing mail-server-name pops-up and fetchmail bails out complaining
that it doesn't match the mailhost. At home I've more luck
specifying "Delivered-to:" as header-field to parse. My ips's
MTA (postfix) adds those containing the To-envelop header. And
that header has the expected host name. We have to have a look
at your headers after receiving mail to figure out if this could
work for you. Here it is working, nontheless I have added this
"no dns"
> fetchmail: no local matches, forwarding to tony
As the mailhost was not the same as the pophost fetchmail failed at first.
Now he is using the fallback deliver address (postmaster)
> Notice how there is another rejection, now of mti*24.worldnet.att.net
> Perhaps using wild * can fix it? Something like aka
> mtiwgwc*.worldnet.att.net?
I had no luck trying this tonight.
> It also bothers me that the mail comes to "tony" after bouncing, and I had
> defined "arodriguez is tony
> here".
Yes, but fetchmail chookes over those changing mailhosts and falls back
to delivery to postmaster. This will change once we got that sorted out.
> Also, notice how in my previous posting there is the line
> **** this below
> About to rewrite Sender: tony
> Rewritten version is Sender: [EMAIL PROTECTED]
Your mail agent (mutt?) or exim isn't configured properly, all mailheaders
should have fully qualified email addresses. And a fully qualified domain
name has at least 1 dot in it.
--
groetjes, carel
