At 13:19 2001-11-16 +0100, Jonas Meurer wrote:
Hello,
Hello. You've posted pretty much the same request three times
now. Resending it a bunch of times isn't going to change the fact that
people here may not be prepared to walk you through the process of dealing
with messages which may have long since lost their original envelope
addresses. I don't really have the time to deal with this either, but it
looks as if you don't get an answer, you're going to keep posting this at
least twice a day until you do.
How can I get the receiver adress? The problem is, that mails send to
***(_at_)server0(_dot_)de are forwardet by the provider to gmx,
# host -t MX server0.de
server0.de mail is handled (pri=10) by mailin.webmailer.de
Is this ="gmx", or is this the "provider" that is forwarding to "gmx" ?
and fetchmail fetches the mails from gmx.
Keep in mind that this forum isn't a support forum for fetchmail, so if you
have configuration issues with that program, you'll need to check it's
documentation for information on where to send queries about it (presuming
that you've first read the documentation for it).
Then the mails to *(_at_)server0(_dot_)de are in my mailbox, but I wanna have them
send to the local *(_at_)server0(_dot_)de
Your "mailbox" is on server0.de? "local" could mean "local to your
network", or "local to this machine".
I've got to wonder why, if there REALLY is a server0.de (and DNS seems to
indicate that there is), that you don't just set up a backup MX
(mailin.webmailder.de acting as a spool, but not your final mail server,
and not forwarding the messages) and use fetchmail to 'tickle' that system
with 'ETRN' to pass the messages via E/SMTP directly to
server0.de. Procmail doesn't need to be involved with parsing out
recipients at all.
I presume that server0.de isn't on a fulltime net connect -- but if you'd
just use a ddns service, this wouldn't pose a problem. In fact, if your
server were configured to be the primary MX, then if you were online at the
time, the mail would actually be delivered directly to you.
It appears to have an A record though, as dig reports:
server0.de A (Address) 192.67.198.52
It'd provide a direct route for your email, allow your mail to actually
arrive via SMTP instead of being "fetched" via POP/IMAP, and would
generally be FAR more efficient on network bandwidth consumption.
Also, you will find that you have problems when there are multiple local
recipients on a message, and you receive only one copy of the physical
message for processing... This is ugly within procmail, which is intended
to act as a LOCAL delivery agent, not as an MTA go-between:
To: user1(_at_)server0(_dot_)de, user2(_at_)server0(_dot_)de
Cc: user3(_at_)server0(_dot_)de
Bcc: user4(_at_)server0(_dot_)de (this header doesn't even _appear_)
For reasons such as this, you *REALLY* don't want to use procmail as an MTA
go-between - it isn't a _failing_ of procmail, it is just that it was not
designed for this purpose. You'll have a newfound respect for this
limitation once you have to process messages with multiple local recipients.
so I have to set a filter with procmail which simply sends mails with
*(_at_)server0(_dot_)de as receiver to the receiver
Why isn't fetchmail delivering them properly? Do you not have fetchmail
configured properly?
so that they are send localy. This is important for progs which make
things if they receive a mail like mailman.
If you still insist on using Procmail as an MTA go-between, then try this:
send a VERY SHORT test message to yourself (at some alias on your server
specifically NOT the account that fetchmail is using for local delivery),
then take the COMPLETE headers of that message and post them here, in reply
to this message (trimming all of my content out of the reply of course,
because that's the proper thing to do). THEN we'll have some idea of what
headers you have available to trigger off of, if any.
Also, indicate if you have configuration control over the sendmail on the
server0.de machine (I assume you do, but that is just an
assumption). There are sendmail tweaks you can do to have it add an
"X-Envelope-To:" header if needed.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail