1 |
Am Montag, 11. Mai 2015, 04:26:01 schrieb Robin H. Johnson: |
2 |
> This was a good early policy, as Gentoo was a much more reliable host than |
3 |
> email providers a decade ago. This isn't true anymore, with the meteoric |
4 |
> rise |
5 |
> and success of gmail. |
6 |
This is not true at all - but email service "reliability" was and is not a |
7 |
primarily question of the hosts OS nor some kjind of basic standard |
8 |
configuration of a mailer "package" (or ebuild). |
9 |
|
10 |
|
11 |
> As past long-standing practice, @Gentoo.org system-level mail handling for |
12 |
> incoming mail was officially to tag everything, and delete nothing. |
13 |
This is - for a public internet Mailer / MX - a VERY bad option - at least |
14 |
mail not fulfilling basic email standards should be blocked (as usual by the |
15 |
very most professional level mail services), because it could be (used) |
16 |
abusive by thirds. |
17 |
|
18 |
|
19 |
> A LOT of developers forward their mail now, to systems that |
20 |
> refuse/temporarily blacklist the forwarding system because there is a lot |
21 |
> of spam. Gmail is particularly strict in this regard, throttling mail to |
22 |
> any recipient from the forwarding source. |
23 |
Gmail is crap (from my opionion) - at least for really professional email |
24 |
users or at least users which need a reliable email service (includes the |
25 |
possibility to recieve or send out higher frequent emails or emails from more |
26 |
"exotic" sources). |
27 |
|
28 |
We - as a email provider - recognized the development of the rate limiting |
29 |
policy by Google as well and it seems that Google is adapting that limits by |
30 |
the amount of mail which is send from google users into that "domains" (as far |
31 |
as this is correctly locatable for them, because by specs it is not |
32 |
really...). This works OK for source mail servers / domains which still have |
33 |
"typical" email users and their regular traffic (or what googles thinks about |
34 |
- i.e. what some kind of user deletes without reading or is (i.e. false) |
35 |
marking as "spam") going to different recipients at google too, but not very |
36 |
well for more specialized email systems (like mailing list weighted mail |
37 |
systems / MTAs or systems handling some kind of notifications for a larger |
38 |
amount of users / customers - (widely) independent from what type of mail they |
39 |
transport and how high the part amount of spam within is). |
40 |
|
41 |
For mail ISPs there is a contact where they can "complain" or "discuss" about |
42 |
limits with a mail server, but i did not know any case wher any answer was |
43 |
coming from them (does not mean that google did not recognizes it). |
44 |
|
45 |
But if someone decied for google as his primarily email provider - he has to |
46 |
live with that policies from google, which might work OK for most peoples and |
47 |
their "most peoples traffic". |
48 |
|
49 |
|
50 |
> Unless there are any major objections, as of May 17th, Infra will start |
51 |
> dropping mail that scores more than 10.0 points in Spamassassin. |
52 |
> |
53 |
> If that is successful, I propose to drop the score point by 1 point every |
54 |
> month until it hits a score of 5.0 (so by mid-October, it will be dropping |
55 |
> mail that scores more than 5.0). |
56 |
This will work (depending form some of your SA setup details and how far you |
57 |
use all of the features, channels and possible extensions / third party |
58 |
services - i.e. DCC, Razor, Pyzor, "all" the different update channels, Bayes |
59 |
- while disabling DNSBLs and doing that still before in your mailer) until you |
60 |
go down 5. |
61 |
|
62 |
On 6 you typically will still get a lot of spam through (enough to make users |
63 |
work to sort it out regularly) while on 5 you definitely will loose ham - even |
64 |
if you still use the "usual" DNS based spam blocking lists (would let do this |
65 |
the mailer before SA usually because of performance/ressource reasons). |
66 |
|
67 |
So typical "working" values are between 5 and 6. |
68 |
|
69 |
But even then you will get spam, as long if you won't loose any ham "from time |
70 |
to time" - installing a filter solution like SA alone is just one part of a |
71 |
modern and working anti spam gateway with a zero false positive target policy |
72 |
(but might be enough to help your moderators here ß). |
73 |
|
74 |
Most important tasks are to set up the MTA/MDA far enough to block email which |
75 |
are not fulfilling the specs and/or coming from machines which doesnt it - the |
76 |
very most of spam should be catched here usually, but is is a dynamic tasks to |
77 |
know and/or find out which parts of the standards are important and which |
78 |
less, because there are still many used mail systems out which are not |
79 |
configured properly, but have a significant user base. |
80 |
|
81 |
But there are very good reasons why more and more admins of smaller otherwise |
82 |
focussed admins decide to route their email traffic over a gateway mail |
83 |
service. Setting up a "just working" email system is a simple job today, but |
84 |
running a reliable internet email service on a more professional level is a |
85 |
real job which takes time and knowledge in maintaining that service - far over |
86 |
the setup details of a SMTP daemon (i.e. a proper DNS setup with PTR, DKIM, |
87 |
SPF, abuse contacts and so on) which often are out of scope of a typical |
88 |
admin. |
89 |
|
90 |
|
91 |
|
92 |
hth a bit. |
93 |
cheerioh, |
94 |
|
95 |
|
96 |
Niels. |
97 |
|
98 |
|
99 |
|
100 |
-- |
101 |
--- |
102 |
Niels Dettenbach |
103 |
Syndicat IT & Internet |
104 |
http://www.syndicat.com |
105 |
PGP: https://syndicat.com/pub_key.asc |
106 |
--- |