Re: Sendmail, Procmail and (ugh) Exchange

On 05/29/07 14:17, gaa@xxxxxxxxxxx wrote:
I have always been a fan of sendmail with procmail for local delivery. However, the "powers that be" dictate that everyone must use Exchange. No ifs, ands or buts. Due to the crappy filtering available in Exchange, I want to still use procmail. We also still want to use sendmail for handling some other issues (gateway to mailman, etc.).

I *REALLY* am sorry. ;(

Does anyone know how I can have sendmail make the determination of "locality" then invoke procmail for the "local" users, then if the user has not done something else from within the procmailrc file, forward any left over email to the Exchange system?

If you have a mixture of local (to the Sendmail box) and non-local (Exchange) accounts with in the same domain, you could probably use LDAP routing to have Sendmail decide where to send the messages to.

Something else you could consider would be to translate <user>@<domain>.<tld> to either <user>@sendmail.<domain>.<tld> or <user>@exchange.<domain>.<tld> or the likes. Then you could have Sendmail use Mailertable to decide where to route messages for sub-domains to very easily. You could even add a subdomain of mailman.<domain>.<tld> for your mailing lists. This type of abstraction will allow you to grow things as you need down the road too.

With the abstraction layer, you set up all your Exchange accounts to be <user>@exchange.<domain>.<tld> in so far as the email addresses for the mail boxes.

You would still send out as <user>@<domain>.<tld> from Exchange. Alternatively, you you could send out as <user>@exchange.<domain>.<tld> and have Sendmail masquerade the addresses for you. With Sendmail masquerading for you, Exchange ONLY has to worry about exchange.<domain>.<tld>, which may be a good thing.

In other words, there should be no local mailboxes on the sendmail server, however procmail should be invoked for the purpose of filtering, etc.

Hum, this is a bit of a problem. First remember that Procmail is a "Local Delivery Agent" (LDA) that Sendmail calls for local delivery. Sendmail does not call an LDA when it relays mail on to another server. Granted you can have Sendmail deliver everything locally via the Procmail LDA. Procmail would then process as you want and re-send the messages that were not delivered locally. However this breaks the SMTP end-to-end deliver by terminating it at the Sendmail box and re-initiating a new SMTP end-to-end deliver from Sendmail to Exchange. I don't know how sub-optimal this approach is with multiple SMTP end-to-end delivery's, but I do know that there is a lot more overhead involved. If you have the overhead to spare, this may work well for you.

I think I have read somewhere about a way to call Procmail *DURING* the SMTP end-to-end delivery while relaying messages. Googleing may reveal something. I think this has also been talked about in this news group.

Alternatively you may be able to find that MIMEDefang may be able to do what you are wanting as a milter during the SMTP end-to-end delivery.

Here's the flow as I see it (using "example.com" as our domain):
1. Incoming email gets processed by our Spam appliance. It has a
rule to forward everything to the sendmail server
"procmail.example.com".

*nod* This would be the same.

2. Procmail.example.com looks at the email and if it is for
"example.com", it is considered to be local.

This may change, depending on how you tie email to Exchange.

3. Local email addresses get validated against Exchange via LDAP / AD
lookup. The "SamAccountName" attribute corresponds to their Unix
login.

*nod* I think this should be done at the SMTP Edge, i.e. the "Spam Appliance", but I digress.

4. A copy of procmail is invoked as the given user so that people can
do any special processing.

This may change, depending on how you tie email to Exchange.

5. Procmail should not deliver it locally. It should pass it back to
sendmail for processing.

This is where Procmail would re-submit the message to Sendmail to send in to Exchange.

6. All email passed back should go to "exchange.example.com".

Um, 5 and 6 look to be the same to me, but ok.

However:

There are *ALWAYS* exceptions! :P

7. All email from exchange to anywhere outside of exchange should go
to "procmail.example.com" which will forward it to the appropriate
server. I want a chance to handle all email in and out of the
exchange system. (I realize I can't see the totally exchange stuff,
but...)

Simple. Have Exchange Smart Host through "procmail.example.com".

I hope someone can help with this as I don't really want to deal with
the thousands of automated messages, Spam, etc. I get every day as
the admin here. That is what filters are for.

I'll help you by shooting you. <BANG> I think you know why I say that too.

If it was not for the desire to do filtering via Procmail, you could easily use an abstraction layer in combination with Mailertable to route messages based on different subdomains. However you can use LDAP routing to route individual addresses to what ever internal mail server you want. If you could have Mailman listen on port 25, you could have Sendmail relay messages destined to Mailman via LDAP routing too.

So, in short you can use either LDAP routing, or an abstraction layer in combination with Mailertable and subdomains. Either of these will fulfill your desire to route messages fairly well.

The real problem is the interaction with Procmail. Procmail is better or worse than any thing else. The problem is that Procmail is (by default with out hacking) a Local Deliver Agent. Sendmail does not involve LDAs in a mail relay process. So if you could re-engineer what you are doing with Procmail as a milter of some sort, you would be a lot better off. If you do use LDAP routing, you could have the people that do not need / want to run Procmail recipes messages routed directly to Exchange and have those that do want to run Procmail recipes locally to the Sendmail system. This way, you are not breaking the SMTP end-to-end delivery unless Procmail filtering is needed.

If you do need to pass a message on that did not match any conditional recipes onward in to Exchange, you would need to send the message to a different email address. This is because LDAP routing will see that user1@xxxxxxxxxxx is LDAP routed locally and will thus be re-delivered locally to Sendmail, thus looping the mail. One possible solution to this would be to write a simple little script that would connect to port 25 and do an SMTP delivery from the Sendmail system to Exchange at the end of the Procmail recipe. If you do go this route, I would make sure that you have the script written such that it can return success or failure to Procmail so that Procmail can return success or failure back to Sendmail. If you can get the success or failure back to Sendmail, it should be able to handle the (re-)queuing of messages that were not successfully delivered to Exchange.

Good luck.

If you want any more details / clarification on any of this, just ask.



Grant. . . .

.

Relevant Pages

  • Sendmail, Procmail and (ugh) Exchange
    ... I have always been a fan of sendmail with procmail for local ... everyone must use Exchange. ... the sendmail server "procmail.example.com". ...
    (comp.mail.sendmail)
  • Re: Procmail battles
    ... but not everyone receives mail using sendmail - some use ... fetchmail to grab mail from their ISP mail server for instance. ... The option in sendmail.mc for procmail delivery is: ... local delivery should be via procmail. ...
    (Fedora)
  • Re: Sendmail and Spamassassin
    ... I think that it can be done with delivery via procmail. ... > sendmail but what I find is above my head. ... I see there is a milter but I ...
    (comp.mail.sendmail)
  • Re: hylafax changing destination
    ... If you are using sendmail, you should be able to used ... for a standard .forward and then performs a normal delivery. ... procmail is even harder to explain. ...
    (Fedora)
  • Re: /bin/mail local mail delivery
    ... not a transport or delivery mechanism. ... but I thought that sendmail used the local mailer program (i.e. ... Sendmail drops it off to the local spool directory via procmail. ...
    (alt.os.linux.redhat)