On 11. Mrz 2004, at 5:54, Frank Habicht wrote:
You need a slightly different approach.
SMTP to port 25 is 'meant' for all deliveries to your local addresses
(domains hosted with you).
From any machine on the internet acting as an smtp-client to your server.
all this to your local addresses doesn't need auth - because there are so
many thousands of machines out there and you want all of them to email
you...
even if it happens to come _from_ one of your addresses... ... no auth. because _all_ can send email to your addresses (I'm trying currently ;-)
best solution is for your users to send the outgoing mail to esmtp-msa (port 587) or esmtp-ssl (port 465) - by default at least
Well, yes, in _theory_, this could be a possible approach. In practice, it is the default for any mail client to use port 25 to submit mail to its smtp server - be it the terrible Outlook or anything else around. And ssl is not yet present in all mailers.
I'm actually trying to solve a serious spam problem:
spammers sending mail claiming to be someone of my domain, asking people
to send their user id and password, etc.
I've written a perl script that can make (fairly) sure if one is
authenticated - but I can not just throw away the "other" mails, i.e.
those which are not authenticated (and still have a "From: " header
pretending to be from the same domain) because I cannot tell, at that
level, whether it's a spammer or a user with an old client who tries to
send some mail without authenticating first.
If the server forced authentication for those claiming to be a hosted user
at the Return Path (MAIL FROM) level, spammers could still claim to be
someone else and later, in the DATA, use a "From:" of my domain. But in
the latter case I could easilly catch that with my maildrop-triggered
script.
Of course, a last-resort option would be to make an extfilter out of the script, and alter the subject or body, telling that it could _possibly_ be spam and not to trust the sender in case of doubt. But an error at SMTP level, which the users would inevitably notice and force them to update/setup their clients would be much better. I've setup Communigate Pro several times - and its smtp module has this option for example. I can't believe that an otherwise superb product as courier is going to "leave me alone" on this issue... :|
BTW: I do use spam assassin succesfully with maildrop - in this case, though, the problem is not the content of the message which is no advertisement but an attempt to make users give away their passwords or execute attachments. And of course I warned all users... but ... yes.. I hate _those_ spammers in particular and would like to find a server-side solution ;]. Smtp auth works fine in courier, why shouldn't I use it...?
there you require auth: AUTH_REQUIRED=1
hope it helps...
Frank
PS: yesterday i struggled with a fairly fresh install to get a virtual
domain in $(sysconf)/aliases/* work...
it took too long to get the idea to create a .courier-default in the
recipient's home....
It's kind-of implied, but an additional sentence under Virtual domains would
help saying something like
you have to accept all these emails with a .courier-default file or
individual others... ?
this is a helpful one :) i also hadn't figured this out....
indeed courier has a lot of docs but somehow i'm always searching like mad
maybe i'll have to get used to it ;).
Finally: Lots of thanks to Sam for courier!!!
I agree :)
Lorenzo
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
