At 12:16 2010-01-08 -0800, Bart Schaefer wrote:
So the new recipe attempts to discern the local user by examining the
delivered-to header because there is no local user in any of the
headers matched by the ^TO_ macro.
The question is, is Delivered-To: inserted at his sendmail
(formail->sendmail->procmail), or is it inserted by his upline
ISP? Ultimatley, I guess it doesn't really matter, because among those in
the know, we know this forwarding approach only leads to more problems...
If one *MUST* forward, perhaps the solution would be to invoke $SENDMAIL
*WITHOUT A DOMAIN QUALIFIER* on the user address, so that the local
sendmail config doesn't attempt DNS resolution to find an MX, upon which it
discovers that the message isn't LOCAL?
At a shell:
sendmail -bv chris chris(_at_)pinefields(_dot_)com
If the FQDN doesn't report as local delivery (as the unqualified one
should), then you're pumping that message off to somewhere else just to get
it back. That's, in a word, silly. There's a few other words that could
be used as well.
BTW, 'host -t MX pinefields.com' reports:
pinefields.com mail is handled by 10 inbound.pinefields.com.netsolmail.net.
So, chances are, when delivering mail for @pinefields.com from the local
system, it's being pumped off to that netsolmail.net host. However verizon
gets into the mix is news to me - is it possible that netsol forwards it to
a dropbox at your broadband ISP?
Message ID and SMTP transaction codes could all come into play with a loop
detection at Verizon. The solution is to NOT forward mail when there's no
clear need to do so.
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail