On 9 Oct, Jason Williams wrote:
| Thanks for the input. I've had someone really helping me with this, but we
| keep running into a mail loop, and we are wondering if the problem is due
| to postfix.
|
| Answer to your questions:
|
| >Is the machine the messages are forwarded to configured to accept local
| >mail (i.e. w/o fully qualified domain?)
|
| The mail server that procmail is running on, is setup to deliver mail
| locally. All email comes in from a mail gateway server and is delivered
| locally on my actual mail server. I've tested just sending a normal, plan
| email through procmail, and it gets delivered correctly.
|
| >Is it supposed to accept mail from localhost?
|
| Yes.
|
|
| >Is all this taking place on the same host?
|
| Yes, the actual mail server itself.
|
Everything that follows the next paragraph was already written when
another thought occured to me. I'm adding it up top in case it's a
quick fix, though I doubt it. Is it possible that postfix is smarter
than sendmail about the way it interfaces with procmail as LDA? Could
it be waiting around to find out that "delivery" was actually a forward
and that it's going to create a loop? I doubt it because it would have
to know a lot more than it possibly could about what procmail will do
with the forwarded message. Alternately, are the logs displaying an
actual loop rather than a suspected or potential one, comparable to
sendmail's "too many hops" error? This is part of the problem with
trying to diagnose software you know nothing about.
Assuming the original recipient is NOT spamcop(_at_)courtesymortgage(_dot_)com,
try the following and see it it fixed the problem.
:0
* ! ()\<spamcop(_at_)courtesymortgage\(_dot_)com\>
* ^(X-Spam-Flag: YES|Subject:.*\[SPAM\])
! spamcop(_at_)courtesymortgage(_dot_)com
The rest of this is my original flailing ...
Does local mail go directly to the internal server, or does it go
through the gateway?
I'm going to guess local mail usually never touches the gateway, which
only handles mail from the outside. A further wild guess is that
something in the way you're forwarding this message is not routing it
typically, but is sending it through the gateway which is sending it
back to the internal server; and something in that process is making
postfix think there's a loop. For example, if internal mail is usually
sent with a recipient that's a user name only (which the server knows
is local), but the forwarded messages in question are being sent with
@courtesymortgage.com, that may be causing them to go through the
gateway. Or maybe it's not going through the gateway and your internal
server doesn't know to accept mail with user(_at_)domain(_dot_)tld (as opposed
to
user, or user(_at_)localhost, or user(_at_)host, or
user(_at_)host(_dot_)domain(_dot_)tld).
If you're not sure, check Received: headers on a typical local message,
and on one of the problem messages. Try forwarding messages using
different methods (e.g. the mail client software you use) to the same
address in exactly the same format as you're trying to do with
procmail. Try a different address and see if differences, if there are
any, tell you anything. If my guesses about the addressing of local
mail are correct, try sending a message to a local user on the local
machine using user(_at_)domain(_dot_)tld(_dot_) It might seem that these
should all be
the same, but they're not necessarily handled the same way by the MTA
(more below).
I have a very similar setup to yours -- a gateway server and an internal
mailhub that serves the whole LAN. The hostname of the mailhub is vela.
This is a name that's known internally only. Sendmail on that machine
is *specifically* configured to acccept mail from:
localhost vela vela.tradersdata.com mail.tradersdata.com tradersdata.com
I don't recall the details, but I had problems with a system upgrade
where sendmail did not get properly configured as above. IIRC the
internal MX records told that machine to deliver local mail to itself,
but sendmail hadn't been told to accept it. Since sendmail didn't know
to accept it, it looked for the next hop and (internal) dns told it the
next hop was itself. It caused the "mx points back to myself" error
mentioned earlier. Your's sounds suspiciously similar to that. Maybe
not exactly, but some similar misconfiguration. Check that /etc/hosts,
dns (if you use it), and postfix are all in agreement about all the host
names, aliases, and ip addresses that the machine is known by and is
supposed to accept mail for.
I really think it's a postfix problem and, since I don't know anything
about postfix, I don't have any other ideas. You'd be more likely to get
meaningful help in a place where it's on topic and people hang out that
know the software. Try alt.comp.mail.postfix. Last time I looked it
was pretty low volume, but at least the people there probably have more
expertise.
| >The original message indicated a procmail recipe that forwarded
| >specifically to spamcop(_at_)courtesymortgage(_dot_)com(_dot_) The postfix
log entries
| >indicated messages to and from spamcop(_at_)acme(_dot_)com(_dot_)
|
| That was my fault...everything should be going to
spamcop(_at_)courtesymortgage(_dot_)com
|
|
| >How did those change and what is the relationship between the two
| >domains?
|
| See above. My fault. :/
|
A polite suggestion. Think twice about munging logs and other
information when seeking technical help. Sometimes it's appropriate,
but more often it's really not necessary. People end up eliminating or
changing info in a way that makes it harder to diagnose the problem.
It can also cause other, unforseen problems. Be prepared to start
getting real spam at your spamcop address. I've seen this list
harvested less than 5 days after starting with a new throwaway address.
The unforseen or unintended here is that the spamcop user at acme.com,
which I presume has nothing to do with you, will also be on the
spammers lists in no time. That's unfortunate for them. If you're going
to redact information, keep it nondescript and unresolvable, such as
hostname.domain.tld. That avoids causing problems for others AND let's
those trying to help know clearly that the info has been munged.
--
Email address in From: header is valid * but only for a couple of days *
This is my reluctant response to spammers' unrelenting address harvesting
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail