Strange, I have an opposite opinion on the most of catch-all and delete
usage I'm reading here in this thread.
Personally, and as provider of email business, I consider catch-all
account useful only when you have a new domain, and customer does not
know which mailboxes were running. So you set up a catchall account and
start creating all necessary accounts, and stop catch-all when the most
of accounts are created.
About deleting all email for not existing users, I consider it a bad
service to customers, as they have legitimate raports with business
partners, and if someone writes to the wrong address it is correct and
ethical to report them back that address is wrong, so they can use
another way to contact the recipient, instead of waiting for never
coming reply messages.
More, the abuse of deletion and missing respect for RFC forces users to
ask always for delivery and read receipt, incrementing the volume of
useless emails.
About signing headers with authenticating sender address, is a must
because it makes senders responsable for what they are sending, and the
most of our business customers wants their domain to be used only for
legitimate emails,
Of course other opinions may be based on different needs, but I think
respect of RFC should always be at first place, otherwise people will
look soon for other stable and reliable message delivery methods.
Something I think often about: as email providers, we should look like
real postmen: we cannot read (intentionally I mean), lose, damage others
emails. Virus and SPAM must be fought, and apart real viruses and real
spam all the remaining MUST be delivered. Any not valid damage or loss
could be legally pursued.
Regards,
Tonino
Il 19/05/2014 21:10, Eric Shubert ha scritto:
On 05/19/2014 08:06 AM, Jim Shupert wrote:
How might one do - have a DELETE rule for badly addressed messages. I
just drop them and forget about it?
is it as easy as: " Set catchall email deleted " from admin
in truth ... i thought you HAD to have a catch all account -- yes - i
would rather not.
thanks
Personally, I use a catchall account for my domain, and I don't get
very much spam there at all. I do a few use a few tools for mitigating
this.
1) the badmailto file can specify addresses with a regex. So for
example, if your domain accounts don't contain numbers or whatever
special characters, or your accounts always follow a certain pattern,
you can write badmailto rules to reject these attempts. I used to get
a lot of spam with numbers in the account name, and eliminated them
witha few badmailto rules. This file can also be used to reject
messages to defunct accounts.
2) use spamdyke to blacklist local domains. This seems counter
intuitive, but so long as legit users always authenticate and only
send email via your server, this works nicely.
That being said, I can see where some domains would want to simply
delete these messages. While deleting messages goes against the RFCs,
doing so certainly appears to be a best practice. Some rules, while
well intended, have unintended consequences. I think this is one such
rule.
also that strategy of : " giving each user a separate mailbox name and
e-mail address "
yes , that is interesting -- I can see how that would work
....unfortunately in my current situation folks already have the
"configuration " that we have.
but maybe for a new bunch of folks a new domain
This is a most excellent method of managing user accounts. I've
considered doing this, but haven't actually implemented it yet. Along
these lines, I've also considered modifying the header record qmail
adds so that the authentication account isn't listed in its entirety.
This would help to protect the actual account name.
thanks for the food for thought ,,, a hardy meal.
jim
Thanks as well.
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it to...@interazioni.it
------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
