On 22 Aug, Klas Brink wrote:
|
| uwe(_at_)uweklaus(_dot_)de wrote:
|
| > OK, thank you, but can you explain me something about that?
|
| ^.*for\ *<?
| is there to catch mail that has been forwarded (e.g by procmail on another
| machine :-)
| to one of your recipients (e.g aaa(_at_)domain(_dot_)de). The address
(aaa(_at_)domain(_dot_)de)
| will not appear in the To:, Cc: fields of the header then, but it can be found
| in the
| "routing part" of the header (which normally says something like "... for
| <aaa(_at_)domain(_dot_)de> ...".
| The above regex finds such a match.
|
|
| > The ^.*for\ *<? matchs the BCC too?
|
| I'm not sure, however, about Bcc:, but I __think__ it will catch such mail.
| Expanding the TO_ macro indicates that it should match on Bcc:, but I've never
|
| seen a header Bcc: in a mail (and why should I, I mean, you normally use Bcc:
| to make the address "invisible" to other recipients of the mail).
| But the mail gets routed to the correct mailbox and that ought to be reflected
|
| by the routing part of the header, so yes, it should catch Bcc'ed mail as
| well.
The routing takes place during the SMTP conversation between MTAs.
While it may be true that typically this information ends up in a
Received: header, there's no guarantee of that and the presumption that
it must be there for the mail to be routed properly is incorrect.
I haven't looked closely at the recipes Klas suggested for Uwe, so don't
have any specific help to offer. But it's discussed here with some
frequency and, in general, routing email using header information is
less than a 100% proposition. Unless you control the MTA there's no
guarantee that all the necessary information get written to the
headers, and even then it might not be a certainty (see next paragraph).
Here's one example. There may be others. When mail comes in where there
is more than one local recipient, the Received:.*for pattern you're
depending on isn't there. So if there are multiple people at the domain
subscribed to the same mailing list, this match may fail. I don't know,
but it might even be certain to fail. FWIW, I have my sendmail server
add an X-Envelope-To: header and it also does not appear under the same
circumstances. Bottom line is 100% effective mail routing based on
headers is difficult at best.
I haven't put much thought in to implementing mail routing from a
multi-drop box because I don't need to. In general, this is something
better solved at the MTA level than LDA. Barring that, maybe Uwe's ISP
could help. If they're running sendmail, and if Uwe can run procmail
there as opposed to (or in additon to) his local machine, maybe
something like sendmail faq #3.29 would help:
http://www.sendmail.org/faq/section3.html#3.29
I don't know that this avoids the situation I described above with
multiple bcc: recipients, but I'd guess it would because it's taking
place at the MTA level where it must. If the ISP doesn't run sendmail,
maybe the faq will give them an idea to implement something similar with
their MTA.
Lastly, the space " " doesn't need backslash escaping in the regular
expression. And I'm not sure what the RFCs say about the format, but
I'd substitute [ ]+ for that space (where the character class
contains a space and a tab character). Also, if it were me, I'd make it
^Received:.*\<for[ ]+<?\/[^@ ]+(_at_)domain\(_dot_)de, but I tend towards
overly anal caution. I also think the "<" is always there, so you
don't need the "?" modifier. But I may be wrong, and it probably hurts
nothing.
--
/"\
Don Hammond \ / ASCII Ribbon Campaign
Raleigh, NC US X Against HTML Mail,
/ \ and News Too
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail