> Unfortunately, I'm not that familiar with MS Exchange server.  I'm just
> wondering if it works more like Sendmail where the domain name is
> irrelevant to the username - so an e-mail sent to the alias
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> will actually be deposited
> into the [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> account - or if domain
> must match?

I'm not familiar with it, either.  Bowie suggested that you may need to
add another address to each of the Exchange users.  If that's so, only
the Courier host would use those addresses, neither local users nor
remote senders should ever see them.

I think the problem is resolved now - Exchange acts as I'd expected, at least for two e-mail addresses - [EMAIL PROTECTED] and [EMAIL PROTECTED] - which is perfect.

   > snip...
> accounts because Courier automatically routes e-mail to the Exchange
> box, untouched.  This is why I'm suggesting one small filter that checks
> to see if an account is valid - and the ldap idea sounds like a really
> good one.

I don't think that any of Courier's filtering capabilities are going to
fix the problem though.  The courierfilter stuff happens after the DATA
phase, so it can't reject individual users, and the localmailfilter
stuff only works if the users are valid local accounts.  You might be
able to hook in with the alias-filteracct setting, but it's hard to say
without knowing more about *how* Courier's been configured to route mail.

In any case, an alias database which redirects only valid accounts is
probably the least amount of work, and the most reliable of solutions.

An alias database is twice the work - a new user account would have to be entered in the Exchange system, into Courier's auth system, and then an alias created.

Sam pointed out to me that if I update Courier to the latest version that routed domain recipient rejections will be dropped immediately - which is not what my current version does.  So honestly, all I really need to do is update Courier - which I'm working on now and it should totally solve my problem.

   > What I currently have works "ok" - but maillogs roll and the logic to
> prevent reparsing large logs seems a bit daunting as well.

Keep it simple: only parse what you read while watching the end of the
file for appended data.  Make sure that whatever rotates your logs
(logrotate?) notifies your parser when it rolls logs.  It should be a
simple matter of adding a "kill -HUP <pid>" to the logrotate postrotate
script for the maillog file.

Well, again, this is kind of a moot point as the newer version of Courier implements a tarpit against ports 25 and 587 as Sam just mentioned to me yesterday so doing this will probably be overkill.  I'm anxious to see if the behavior stops to a negligible level - if it doesn't then I'll reconsider what you're saying here, which is correct.  The app will still have to handle log rotation from newsyslog and I'm not 100% familiar with whether or not syslogd keeps the pipe open or if it eventually closes it...

Thanks,

D

   It won't be.  If your application fails for any reason, you're going to
lose logs entirely.  In order for log rotation to work reliably, you're
still going to have to modify your logrotate configuration, and you're
still going to have to make sure that your program handles HUP signals
properly.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users



--
Derrick T. Woolworth, President
ServeTheWeb, LLC.  http://www.ServeTheWeb.com

Reply via email to