<div dir="ltr">Thanks a lot guys!<div><br></div><div>It seems we still have some spam that can't be catched easily by spamassassin. I find some of them in systems@.</div><div><br></div><div><i>X-Spam-Status: No, score=1.3 required=3.5 tests=HTML_MESSAGE,RDNS_NONE, SPF_HELO_PASS,SPF_PASS,T_<wbr>REMOTE_IMAGE <br></i></div><div><br></div><div><div><i>X-Spam-Status: No, score=3.0 required=3.5 tests=RDNS_NONE,SPF_HELO_PASS, SPF_PASS,URIBL_BLACK</i> </div></div><div><br></div><div>Yes, the score is low...</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 5, 2017 at 1:07 AM, Sebastian Silva <span dir="ltr"><<a href="mailto:sebastian@fuentelibre.org" target="_blank">sebastian@fuentelibre.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Bernie for following up and pledging to continue your leadership<br>
in this regard.<br>
<br>
My email-fu is also out of date, but count on me for help.<br>
<br>
Regards,<br>
Sebastian<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 05/09/17 00:02, Bernie Innocenti wrote:<br>
> On 09/04/2017 09:26 AM, Sebastian Silva wrote:<br>
>> I'm not aware of how sunjammer treats mail. Bernie, did you set this up<br>
>> originally?<br>
> Yes. We use Postfix + spamass-milter with a bunch of RBLs and other rules.<br>
><br>
> The reason we're seeing mail with "X-Spam-Flag: YES" in mailman was that<br>
> there are two distinct thresholds: the one in /etc/spamassassin/<a href="http://local.cf" rel="noreferrer" target="_blank">local.cf</a><br>
> causes mail to be flagged as spam when it reaches the score 3.5. This<br>
> doesn't cause the mail to be rejected at SMTP time, just flagged so that<br>
> local delivery rules can move it to a spam folder where users can still<br>
> find it in case it was misclassified.<br>
><br>
> Mailman doesn't have any knowledge of the SpamAssassin headers, but<br>
> there are per-list spam filtering rules. Looks like the "X-Spam-Flag:<br>
> YES" rule was not present on sugar-devel (it's present on systems@ and<br>
> other lists). So I just configured it to silently discard spam. You can<br>
> change it here:<br>
><br>
>   <a href="http://lists.sugarlabs.org/admin/sugar-devel/privacy/spam" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/<wbr>admin/sugar-devel/privacy/spam</a><br>
><br>
><br>
> There's also a second threshold, which was conservatively set to 8.0,<br>
> which is used by spamass-milter to refuse incoming mail with a permanent<br>
> error to the sender. The email in question had a score of 7.7, so it<br>
> didn't make the cut. I lowered the threshold to 6, which should be safe<br>
> enough.<br>
><br>
><br>
>> Maintaining mailservers is often time consuming and frustrating because<br>
>> of spam.<br>
> Indeed :-(<br>
><br>
> Even using with a well configured SpamAssassin, with DKIM and RBLs,<br>
> there is way too much spam that makes it through. The only way to filter<br>
> spam effectively is to rely on signals from a massive number of users to<br>
> train an advanced spam classifier (and SpamAssassin is an ancient<br>
> codebase mostly based on manually crafted rules).<br>
><br>
><br>
>> I don't even fully understand what James said (does gmail consider this<br>
>> spam as originating from SL?).<br>
>><br>
>> Perhaps we should disable mail processing altogether if no sysadmin can<br>
>> manage it.<br>
>><br>
>> While I am in infrastructure team, mail is just too time consuming to<br>
>> configure for me.<br>
>><br>
>> If there's no other volunteer I can look into scaling our mail services<br>
>> down to just mailing lists.<br>
> My experience administering email is 6 years out of date, but I can<br>
> pledge to keep the current system running until we switch to mailman3<br>
> which (hopefully?) has a modern, well thought way to deal with spam.<br>
><br>
> There shouldn't be much to do for the forwarding email addresses, since<br>
> spam filtering belongs in the receiving endpoint.<br>
><br>
> The other thing that can get tricky is ensuring reliable delivery on IPs<br>
> that can be used to send out occasional spam (from local email accounts<br>
> or web apps). This is why we're not encouraging hosted email accounts on<br>
> sunjammer.<br>
><br>
><br>
>> Regards,<br>
>><br>
>> Sebastian<br>
>><br>
>><br>
>> On 03/09/17 17:14, James Cameron wrote:<br>
>>> This will do significant reputational damage to Sugar Labs mail<br>
>>> domain, identifying the mailman instance as an open relay, making the<br>
>>> upcoming election harder to run.<br>
>>><br>
>>> About a thousand messages so far.  I'm intercepting with procmail.<br>
>>><br>
>>> Each has UTF <a href="http://6616c.com" rel="noreferrer" target="_blank">6616c.com</a> in subject, with remainder of subject and body<br>
>>> text in Chinese.  <a href="http://6616c.com" rel="noreferrer" target="_blank">6616c.com</a> is an alias for <a href="http://006cc.com" rel="noreferrer" target="_blank">006cc.com</a>, which looks to<br>
>>> be gambling focused.<br>
>>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Systems mailing list<br>
>> <a href="mailto:Systems@lists.sugarlabs.org">Systems@lists.sugarlabs.org</a><br>
>> <a href="http://lists.sugarlabs.org/listinfo/systems" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/<wbr>listinfo/systems</a><br>
>><br>
<br>
______________________________<wbr>_________________<br>
Systems mailing list<br>
<a href="mailto:Systems@lists.sugarlabs.org">Systems@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/systems" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/<wbr>listinfo/systems</a><br>
</div></div></blockquote></div><br></div>