I wrote:
This is not especially difficult really,
and it may be best practice and so on and so forth, but most ISPs don't do
this.
[EMAIL PROTECTED] wrote:
If they don't do that, then what are they doing? How do they prevent other
users to misuse their servers for sending mail? If they don't do some kind of
authentication then they are a open relay.
I see the typical ISP SMTP setup here is a host or hosts, which will relay all
email to the ISP's domain, and relay all email to all domains, provided the
connection is from their IP address pool.
IOW, their customers do indeed get a relay, because they need one to send
email, but it's not open, it's only for the IP addresses of the ISP's
customers. I haven't come across an ISP before who forces authentication to
send email; however some block port 25 out, and some block port 25 in/out of
the customer address pool.
Now I haven't done or read of an audit of the hundreds of Aussie ISPs, but I
know that the telstra, optus, aapt, iinet and a few other smaller ISPs all
don't enforce auth for their users to send email.
Is this what you're saying? Do you get any customers who complain about
having to auth to send mail?
No. No one complains. In the old days I used to have POP before SMTP but today every client supports SMTP AUTH and it is common to do authentication for sending mails.
It's not common to do auth here in Australia; can anyone comment on USA ISPs?
We live in a world where allowing every one to send mails over your server is very dangerous.
Hyperbole. It's spam; you'll get flooded or blacklisted or both, and have your
reputation damaged. I think that 'very dangerous' is a bit over the top.
Without SMTP AUTH I would expose my self to much bigger problems. Imagine all
those spam bots/trojans/etc sending mail from a clients system.
They can do this anyway, either directly through port 25 if you've not blocked
it or by MAPI API calls in windows, which I accept is less common behaviour.
This would be a mess if I would allow them to send unauthenticated mails over the server. I would be in no time on some blocking list and this is what I want to prevent.
Authentication doesn't stop your users sending spam. It stops many bots
though, but if John Doe wants to send the spam he still can, and your server
will still get blocklisted. Of course, he might get arrested later, but that's
not the point here. I'm intruiged that you find it so likely that your
subscribers would be a source of spam without authentication.
And imagine if I would allow everyone out there to claim to be "John Doe <[EMAIL
PROTECTED]>" and would allow them to send forged mails. This would be bad.
Forged email headers are common; regardless of what you do in your ISP, in
general it is ignorant or foolish to accept any email from: header as proof of
authorship once it's travelled over public networks; as I said, my experience
is that most ISPs don't enforce auth to send mail out, they set relay
permissions by IP addresses.
Postfix (after 2.1) makes it very easy for me to enforce SMTP AUTH.
I suspect that if all ISPs ran their outbound mail as you do, we'd have a lot
less spam.
Using the global aliases for training/retraining is just one way of training
DSPAM. You can still implement the DSPAM web ui and train that way. If you have
a directory you can use to authenticate users from within your HTTP server then
this might be a possible solution. I have users hating to train the anti-spam
filter. So they refuse to do training. I have users where they love the web ui
and hate the global training alias. And I have users where they hate everything
which is not implemented directly in their mail client. So I am forced to allow
many ways for training/retraining DSPAM. I personally prefer the web ui but
this is me. I have users where explaining the web ui would be a crazy task.
They just don't get along with the web ui. It is to hard for them. But two
simple buttons (a big red X with the text SPAM and one green check mark with
the text NOT SPAM) in their inbox is what they understand.
I have users sitting behind IBM Notes or behind MS Outlook. And both products allow you to integrate buttons with logic in the client.
Would you provide me with your outlook plugin? Is it publicly available code?
Spambayes works fairly well but dspam gives me the powerful advantage that lazy
and new users still benefit.
--
Daniel Rose
National Library of Australia
