You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Philip Prindeville <ph...@redfish-solutions.com> on 2014/10/13 08:35:21 UTC
.link TLD spammer haven?
Every connection I’ve gotten from a hostname resolving to *.link or saying helo *.link has been spam (I block the connections with MIMEDefang).
Has anyone actually seen a legitimate email from a host in the .link TLD?
I’ve seen (last week alone):
bgo.blc-onlineconsumer140.link
ratio.allgiftcardsonlinefriendly.link
ratio.autodealersstarted.link
ratio.forincreasemensvitality.link
ratio.growingmedicareprovider.link
ratio.instantarrestrecordseducate.link
ratio.invitegiftcards.link
ratio.largelycarsavings.link
ratio.medicaresourceshigh.link
ratio.publicarrestrecordsdaily.link
ratio.readybloodpressuremonitor.link
tcvd.internetspecial-week242.link
tcvd.internetspecial-week243.link
tcvd.internetspecial-week244.link
tcvd.internetspecial-week246.link
tcvd.internetspecial-week248.link
tcvd.internetspecial-week250.link
tcvd.internetspecial-week251.link
tcvd.internetspecial-week252.link
tcvd.internetspecial-week254.link
vnds.ds-customerreviews101.link
vnds.ds-customerreviews102.link
vps.35dscustomersreviews.link
vps.38-vpscresthosting.link
vps.39-vpscresthosting.link
vps.40-vpscresthosting.link
vps.42-vpscresthosting.link
vps.45dscustomersreviews.link
vps.45-vpscresthosting.link
vps.46dscustomersreviews.link
vtds.customeronlinerev212.link
vtds.customeronlinerev214.link
vtds.customeronlinerev216.link
vtds.customeronlinerev219.link
vtds.customeronlinerev221.link
Is it worth having that triggers on the relay’s hostname being *.link?
Also, I noticed that every message we saw was missing a Received: header…
-Philip
Re: .link TLD spammer haven?
Posted by John Hardin <jh...@impsec.org>.
On Sun, 26 Oct 2014, Karsten Bräckelmann wrote:
> On Fri, 2014-10-24 at 19:05 -0700, John Hardin wrote:
>>>
>>> uri __ALL_URI /.*/
>> tflags __ALL_URI multiple
>
> That seemingly straight-forward approach does not work in this case. The
> tflags multiple option does not make uri rules match multiple times on a
> single URI extracted from the message. It still generates a single hit
> per extracted URI only, not including multiple hits on its normalized
> variations.
That makes sense. Thanks!
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
877 days since the first successful private support mission to ISS (SpaceX)
Re: .link TLD spammer haven?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2014-10-24 at 19:05 -0700, John Hardin wrote:
> On Fri, 24 Oct 2014, John Hardin wrote:
>
> > On Sat, 25 Oct 2014, Martin Gregorie wrote:
> >
> > > Less obviously, it doesn't seem to matter whether you write the rule
> > > as /\.link\b/ or /\.link$/ - both give identical matches. Both match
> > > the following regexes just as you'd expect:
> > > http://www.linkedin.com/home/user/data.link
> > > http://www.example.link
> > >
> > > but, less obviously, both also match this:
> > > http://www.example.link/path/to/file.txt
> >
> > {boggle}
> >
> > > ...but
> > > "grep -P '\.link\b'" matches it, but
> > > "grep -P '\.link$'" does not.
> > >
> > > I presume that this means that the uri rule tests against two strings:
> > > one being just the domain name and the other being the whole URI and
> > > declares a rule hit if either string matches.
Basically correct. SA uri rules are not only tested against the raw URI
as extracted from the message, but also some normalized variations.
Without going into details, OTOH this includes un-escaping, protocol
prefix (if missing) and path stripping.
$ echo -e "\n apache.org/path/" |
./spamassassin -D -L --cf="uri URI_DOMAIN /^http:\/\/[^\/]+$/"
dbg: rules: ran uri rule URI_DOMAIN ======> got hit: "http://apache.org"
Note the regex matching a "domain only" anything-but-slash [^/]+
substring anchored at the end of the string. Also note the input
message's URI lacking a protocol, but the rule hit showing the (default)
protocol added by SA in one variation.
> > I don't think so, but I'm not positive.
> >
> > If you have a testing environment set up, try adding this and see what you
> > get in the log:
> >
> > uri __ALL_URI /.*/
>
> oops. This too:
>
> tflags __ALL_URI multiple
>
> Sorry for forgetting that bit, it's rather important. :)
That seemingly straight-forward approach does not work in this case. The
tflags multiple option does not make uri rules match multiple times on a
single URI extracted from the message. It still generates a single hit
per extracted URI only, not including multiple hits on its normalized
variations.
The tflags multiple option on a uri rule enables it to match multiple
times on different URIs extracted from the message.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: .link TLD spammer haven?
Posted by John Hardin <jh...@impsec.org>.
On Fri, 24 Oct 2014, John Hardin wrote:
> On Sat, 25 Oct 2014, Martin Gregorie wrote:
>
>> Less obviously, it doesn't seem to matter whether you write the rule
>> as /\.link\b/ or /\.link$/ - both give identical matches. Both match
>> the following regexes just as you'd expect:
>> http: //www.linkedin.com/home/user/data.link
>> http: //www.example.link
>>
>> but, less obviously, both also match this:
>> http://www.example.link/path/to/file.txt
>
> {boggle}
>
>> ...but
>> "grep -P '\.link\b'" matches it, but
>> "grep -P '\.link$'" does not.
>>
>> I presume that this means that the uri rule tests against two strings:
>> one being just the domain name and the other being the whole URI and
>> declares a rule hit if either string matches.
>
> I don't think so, but I'm not positive.
>
> If you have a testing environment set up, try adding this and see what you
> get in the log:
>
> uri __ALL_URI /.*/
oops. This too:
tflags __ALL_URI multiple
Sorry for forgetting that bit, it's rather important. :)
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Warning Labels we'd like to see #1: "If you are a stupid idiot while
using this product you may hurt yourself. And it won't be our fault."
-----------------------------------------------------------------------
876 days since the first successful private support mission to ISS (SpaceX)
Re: .link TLD spammer haven?
Posted by John Hardin <jh...@impsec.org>.
On Sat, 25 Oct 2014, Martin Gregorie wrote:
> Less obviously, it doesn't seem to matter whether you write the rule
> as /\.link\b/ or /\.link$/ - both give identical matches. Both match
> the following regexes just as you'd expect:
> http://www.linkedin.com/home/user/data.link
> http://www.example.link
>
> but, less obviously, both also match this:
> http://www.example.link/path/to/file.txt
{boggle}
> ...but
> "grep -P '\.link\b'" matches it, but
> "grep -P '\.link$'" does not.
>
> I presume that this means that the uri rule tests against two strings:
> one being just the domain name and the other being the whole URI and
> declares a rule hit if either string matches.
I don't think so, but I'm not positive.
If you have a testing environment set up, try adding this and see what you
get in the log:
uri __ALL_URI /.*/
Looking at my last test run I see only hits on the full URL, not hits on
the full URL plus hits on only the domain name.
SA still might be doing a double-test in the bowels of the uri rule code
and not reporting it separately, but I think that's somewhat unlikely.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
News flash: Lowest Common Denominator down 50 points
-----------------------------------------------------------------------
876 days since the first successful private support mission to ISS (SpaceX)
Re: .link TLD spammer haven?
Posted by Martin Gregorie <ma...@gregorie.org>.
On Fri, 2014-10-24 at 17:27 -0700, John Hardin wrote:
> On Sat, 25 Oct 2014, Martin Gregorie wrote:
>
> > ..... Does \b match end of string? That
> > never occurred to me. I've always used $ to do that and it certainly
> > works as part of a URI rule.
>
> No, \b matches the transition from a word-character (\w, [0-9a-z_]) to a
> non-word character (anything else, plus beginning and end of line).
>
> Think "\b = Boundary".
>
OK, thanks. I knew it matches word boundaries inside a string but hadn't
got it through my head that it also matches the start/end of words at
the end of strings.
Less obviously, it doesn't seem to matter whether you write the rule
as /\.link\b/ or /\.link$/ - both give identical matches. Both match
the following regexes just as you'd expect:
http://www.linkedin.com/home/user/data.link
http://www.example.link
but, less obviously, both also match this:
http://www.example.link/path/to/file.txt
...but
"grep -P '\.link\b'" matches it, but
"grep -P '\.link$'" does not.
I presume that this means that the uri rule tests against two strings:
one being just the domain name and the other being the whole URI and
declares a rule hit if either string matches.
Meanwhile, I've revised my subrule again and now it reads:
uri __MG_LTD1 /\.link\b/i
So, thanks to all who pointed to this improvement.
Martin
Re: .link TLD spammer haven?
Posted by John Hardin <jh...@impsec.org>.
On Sat, 25 Oct 2014, Martin Gregorie wrote:
> On Fri, 2014-10-24 at 19:48 -0400, Daniel Staal wrote:
>
>> If it does it's behaving oddly. Still, I might try this instead:
>>
>> uri __MG_LTD1 /\.link\b/i
>>
>> That should be faster and more general than the second one above, and
>> shouldn't grab linkedin either.
>>
> The problem is that it won't match URIs of the form
>
> example.link/path/to/badness
>
> which are fairly common in body URIs. Does \b match end of string? That
> never occurred to me. I've always used $ to do that and it certainly
> works as part of a URI rule.
No, \b matches the transition from a word-character (\w, [0-9a-z_]) to a
non-word character (anything else, plus beginning and end of line).
Think "\b = Boundary".
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...to announce there must be no criticism of the President or to
stand by the President right or wrong is not only unpatriotic and
servile, but is morally treasonous to the American public.
-- Theodore Roosevelt, 1918
-----------------------------------------------------------------------
876 days since the first successful private support mission to ISS (SpaceX)
Re: .link TLD spammer haven?
Posted by Martin Gregorie <ma...@gregorie.org>.
On Fri, 2014-10-24 at 19:48 -0400, Daniel Staal wrote:
> If it does it's behaving oddly. Still, I might try this instead:
>
> uri __MG_LTD1 /\.link\b/i
>
> That should be faster and more general than the second one above, and
> shouldn't grab linkedin either.
>
The problem is that it won't match URIs of the form
example.link/path/to/badness
which are fairly common in body URIs. Does \b match end of string? That
never occurred to me. I've always used $ to do that and it certainly
works as part of a URI rule.
Martin
Re: .link TLD spammer haven?
Posted by Daniel Staal <DS...@usa.net>.
--As of October 25, 2014 12:45:31 AM +0200, Reindl Harald is alleged to
have said:
>
> Am 25.10.2014 um 00:42 schrieb RW:
>> On Fri, 24 Oct 2014 21:31:51 +0200
>> Reindl Harald wrote:
>>
>>> Am 24.10.2014 um 21:20 schrieb Quanah Gibson-Mount:
>>>> --On Thursday, October 23, 2014 11:56 PM +0100 Martin Gregorie
>>>>> Thanks for that. I've now installed it and have been running tests
>>>>> against my spam corpus to make sure that this subrule:
>>>>>
>>>>> uri __MG_LTD1 /\.link/i
>>>>>
>>>>> was now working correctly. Its hit all the stuff I thought it
>>>>> should, but my subrule turned out to be deficient because it will
>>>>> also hit any URI containing .linkedin, so anybody who has copied
>>>>> it should rewrite that rule so it looks like this:
>>>>>
>>>>> uri __MG_LTD1 /(\.link$|\.link\/)/i
>>>>>
>>>>
>>>> Even with that change, it always hits mail from linkedin
>>>
>>> logical, the seond part of the "or" is not terminated and defeats the
>>> first one and so the whole purpose of the "or"
>>
>> In the second part the \.link has to followed by a '/'
>
> thanks, i stand corrected
>
> but then it should not catch "linkedin"
If it does it's behaving oddly. Still, I might try this instead:
uri __MG_LTD1 /\.link\b/i
That should be faster and more general than the second one above, and
shouldn't grab linkedin either. (Unless of course they've decided to set
up a .link address...)
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
Re: .link TLD spammer haven?
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.10.2014 um 00:42 schrieb RW:
> On Fri, 24 Oct 2014 21:31:51 +0200
> Reindl Harald wrote:
>
>> Am 24.10.2014 um 21:20 schrieb Quanah Gibson-Mount:
>>> --On Thursday, October 23, 2014 11:56 PM +0100 Martin Gregorie
>>>> Thanks for that. I've now installed it and have been running tests
>>>> against my spam corpus to make sure that this subrule:
>>>>
>>>> uri __MG_LTD1 /\.link/i
>>>>
>>>> was now working correctly. Its hit all the stuff I thought it
>>>> should, but my subrule turned out to be deficient because it will
>>>> also hit any URI containing .linkedin, so anybody who has copied
>>>> it should rewrite that rule so it looks like this:
>>>>
>>>> uri __MG_LTD1 /(\.link$|\.link\/)/i
>>>>
>>>
>>> Even with that change, it always hits mail from linkedin
>>
>> logical, the seond part of the "or" is not terminated and defeats the
>> first one and so the whole purpose of the "or"
>
> In the second part the \.link has to followed by a '/'
thanks, i stand corrected
but then it should not catch "linkedin"
Re: .link TLD spammer haven?
Posted by RW <rw...@googlemail.com>.
On Fri, 24 Oct 2014 21:31:51 +0200
Reindl Harald wrote:
>
>
> Am 24.10.2014 um 21:20 schrieb Quanah Gibson-Mount:
> > --On Thursday, October 23, 2014 11:56 PM +0100 Martin Gregorie
> >> Thanks for that. I've now installed it and have been running tests
> >> against my spam corpus to make sure that this subrule:
> >>
> >> uri __MG_LTD1 /\.link/i
> >>
> >> was now working correctly. Its hit all the stuff I thought it
> >> should, but my subrule turned out to be deficient because it will
> >> also hit any URI containing .linkedin, so anybody who has copied
> >> it should rewrite that rule so it looks like this:
> >>
> >> uri __MG_LTD1 /(\.link$|\.link\/)/i
> >>
> >
> > Even with that change, it always hits mail from linkedin
>
> logical, the seond part of the "or" is not terminated and defeats the
> first one and so the whole purpose of the "or"
In the second part the \.link has to followed by a '/'.
Re: .link TLD spammer haven?
Posted by Reindl Harald <h....@thelounge.net>.
Am 24.10.2014 um 21:20 schrieb Quanah Gibson-Mount:
> --On Thursday, October 23, 2014 11:56 PM +0100 Martin Gregorie
>> Thanks for that. I've now installed it and have been running tests
>> against my spam corpus to make sure that this subrule:
>>
>> uri __MG_LTD1 /\.link/i
>>
>> was now working correctly. Its hit all the stuff I thought it should,
>> but my subrule turned out to be deficient because it will also hit any
>> URI containing .linkedin, so anybody who has copied it should rewrite
>> that rule so it looks like this:
>>
>> uri __MG_LTD1 /(\.link$|\.link\/)/i
>>
>
> Even with that change, it always hits mail from linkedin
logical, the seond part of the "or" is not terminated and defeats the
first one and so the whole purpose of the "or"
Re: .link TLD spammer haven?
Posted by Benny Pedersen <me...@junc.eu>.
On October 25, 2014 2:30:32 AM John Hardin <jh...@impsec.org> wrote:
> >> uri __MG_LTD1 /(\.link$|\.link\/)/i
> > There is still a match on unancored match, remove |\.link\/ and ()
> ...leaving /\.link$/i ?
> You only want to match on a URL that is solely a bare domain in the .link
> TLD?
Its a subrule for meta so imho yes was what the original op wanted
Re: .link TLD spammer haven?
Posted by John Hardin <jh...@impsec.org>.
On Sat, 25 Oct 2014, Benny Pedersen wrote:
> On October 24, 2014 9:20:14 PM Quanah Gibson-Mount <qu...@zimbra.com> wrote:
>
>> uri __MG_LTD1 /(\.link$|\.link\/)/i
>
> There is still a match on unancored match, remove |\.link\/ and ()
...leaving /\.link$/i ?
You only want to match on a URL that is solely a bare domain in the .link
TLD?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...to announce there must be no criticism of the President or to
stand by the President right or wrong is not only unpatriotic and
servile, but is morally treasonous to the American public.
-- Theodore Roosevelt, 1918
-----------------------------------------------------------------------
876 days since the first successful private support mission to ISS (SpaceX)
Re: .link TLD spammer haven?
Posted by Benny Pedersen <me...@junc.eu>.
On October 24, 2014 9:20:14 PM Quanah Gibson-Mount <qu...@zimbra.com> wrote:
> uri __MG_LTD1 /(\.link$|\.link\/)/i
There is still a match on unancored match, remove |\.link\/ and ()
Re: .link TLD spammer haven?
Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On Thursday, October 23, 2014 11:56 PM +0100 Martin Gregorie
<ma...@gregorie.org> wrote:
> On Thu, 2014-10-23 at 17:20 +0200, Axb wrote:
>> As there's a bunch of other new TLDs being abused I would higly recomend
>> updating RegistrarBoundaries.pm
>> from
>>
>> http://svn.apache.org/repos/asf/spamassassin/trunk/lib/Mail/SpamAssassin
>> /Util/RegistrarBoundaries.pm
>>
>> on a Redhat flavour it goes in:
>>
>> locate RegistrarBoundaries.pm
>> /usr/local/share/perl5/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
>>
>> I updated this file yesterday.
>>
>> btw, the file includes instructions so you can update your own file
>> without depending on a SA dev remembering to do it.
>>
> Thanks for that. I've now installed it and have been running tests
> against my spam corpus to make sure that this subrule:
>
> uri __MG_LTD1 /\.link/i
>
> was now working correctly. Its hit all the stuff I thought it should,
> but my subrule turned out to be deficient because it will also hit any
> URI containing .linkedin, so anybody who has copied it should rewrite
> that rule so it looks like this:
>
> uri __MG_LTD1 /(\.link$|\.link\/)/i
>
Even with that change, it always hits mail from linkedin
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Re: .link TLD spammer haven?
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2014-10-23 at 17:20 +0200, Axb wrote:
> As there's a bunch of other new TLDs being abused I would higly recomend
> updating RegistrarBoundaries.pm
> from
>
> http://svn.apache.org/repos/asf/spamassassin/trunk/lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
>
> on a Redhat flavour it goes in:
>
> locate RegistrarBoundaries.pm
> /usr/local/share/perl5/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
>
> I updated this file yesterday.
>
> btw, the file includes instructions so you can update your own file
> without depending on a SA dev remembering to do it.
>
Thanks for that. I've now installed it and have been running tests
against my spam corpus to make sure that this subrule:
uri __MG_LTD1 /\.link/i
was now working correctly. Its hit all the stuff I thought it should,
but my subrule turned out to be deficient because it will also hit any
URI containing .linkedin, so anybody who has copied it should rewrite
that rule so it looks like this:
uri __MG_LTD1 /(\.link$|\.link\/)/i
i.e. it will only match the TLD if it is preceded by a '.' and is
followed by either the end of the URI or '/'. The same will apply to
matching any uri rule that applies a blanket ban to a TLD.
NOTE: this is also insufficiently narrow because it will also match
something like www.example.com/path/file.link but I'm too tired and
hungry to fix that right now: food calls.
I've also written a bash script that automates the process of
downloading and installing RegistrarBoundaries.pm. It has been fairly
carefully tested in the Fedora environment and I think it should work on
almost any other Linux distro because it uses 'locate' to discover where
your system has RegistrarBoundaries.pm installed. Apart from the module
name, only the URI needed to retrieve the module is hard coded - and I
chopped that in three (host name, path and module name) partly to allow
reuse of the module name and mostly because I hate script lines that are
longer than 80 characters. Here you go:
====================== start of sa_newtld script ======================
#!/bin/bash
#
# sa_newtld
#
if [ "$1" == '-?' ]
then
echo "Syntax: sa_newtld"
echo "Function: Replace the existing SA RegistrarBoundaries.pm"
echo " with an updated version."
echo "Options: none"
exit 1
fi
url=svn.apache.org
path=repos/asf/spamassassin/trunk/lib/Mail/SpamAssassin/Util
mod=RegistrarBoundaries.pm
src=http://$url/$path/$mod
tld=$(locate $mod)
curl -o $mod $src
sudo mv $mod $tld
sudo chown root.root $tld
echo "Updated $mod!"
====================== end of sa_newtld script ======================
Martin
Re: .link TLD spammer haven?
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2014-10-23 at 09:31 -0700, sah62 wrote:
> With approximately two thousand new top-level domains
> <https://gtldresult.icann.org/application-result/applicationstatus/viewstatus>
> in the queue for delegation this method of manually documenting validity is
> not going to scale well.
>
Indeed, but so far I haven't seen any of them, apart from .eu, which is
extensively used by the EU and its agencies so cannot be treated as 100%
spam (I need to see EASA bulletins).
> blacklist_from *@*.link
>
Noted, but a lot of the .eu spam I've seen uses either forged addresses
or the address of the bot-infested host in the headers. None of these
are in the .EU TLD, which was only used in body text where the
blacklist_from directive won't find it. This is also typical of spam
that's pumped in via web forums.
I'd expect .link and friends to be used in pretty much the same way.
> This requires manual effort, too, but I can target it to specific problem
> domains.
>
Sure, but the only answer for their use in body text is either a
recently patched Perl module or the configurable list expected in SA
3.4.1.
Martin
Re: .link TLD spammer haven?
Posted by sah62 <sa...@musclecarresearch.com>.
Axb wrote
> On 10/23/2014 05:03 PM, Jesse Stroik wrote:
>> Martin (and others),
>>
>>
>>> As others have already said, URI body rules use a list of valid TLDs to
>>> help with recognising URIs embedded in body text and this list is
>>> currently hardcoded into SA.
>>
>>
>> Thank you for the explanation and the rule. I've put it in place and it
>> appears to work fine with my first set of tests.
>>
>>
>>> which I've tested fairly carefully. All the subrules except __MG_TLD1
>>> work exactly as I wanted them to. I can live with __MG_TLD1 not working
>>> until either a current SA maintenance version is released with an
>>> extended list of hardcoded TLDs or a version using a configurable list
>>> appears.
>>
>>
>> I suspect they'll allow a configurable list of TLDs going forward.
>
> As there's a bunch of other new TLDs being abused I would higly recomend
> updating RegistrarBoundaries.pm
> from
>
> http://svn.apache.org/repos/asf/spamassassin/trunk/lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
>
> on a Redhat flavour it goes in:
>
> locate RegistrarBoundaries.pm
> /usr/local/share/perl5/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
>
> I updated this file yesterday.
>
> btw, the file includes instructions so you can update your own file
> without depending on a SA dev remembering to do it.
>
> h2h
>
> Axb
With approximately two thousand new top-level domains
<https://gtldresult.icann.org/application-result/applicationstatus/viewstatus>
in the queue for delegation this method of manually documenting validity is
not going to scale well. I've had some luck catching this junk by adding
blacklist_from directives to /etc/spamassassin/local.cf, like this:
blacklist_from *@*.link
This requires manual effort, too, but I can target it to specific problem
domains.
--
View this message in context: http://spamassassin.1065346.n5.nabble.com/link-TLD-spammer-haven-tp112305p112502.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: .link TLD spammer haven?
Posted by Axb <ax...@gmail.com>.
On 10/23/2014 05:03 PM, Jesse Stroik wrote:
> Martin (and others),
>
>
>> As others have already said, URI body rules use a list of valid TLDs to
>> help with recognising URIs embedded in body text and this list is
>> currently hardcoded into SA.
>
>
> Thank you for the explanation and the rule. I've put it in place and it
> appears to work fine with my first set of tests.
>
>
>> which I've tested fairly carefully. All the subrules except __MG_TLD1
>> work exactly as I wanted them to. I can live with __MG_TLD1 not working
>> until either a current SA maintenance version is released with an
>> extended list of hardcoded TLDs or a version using a configurable list
>> appears.
>
>
> I suspect they'll allow a configurable list of TLDs going forward.
As there's a bunch of other new TLDs being abused I would higly recomend
updating RegistrarBoundaries.pm
from
http://svn.apache.org/repos/asf/spamassassin/trunk/lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
on a Redhat flavour it goes in:
locate RegistrarBoundaries.pm
/usr/local/share/perl5/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
I updated this file yesterday.
btw, the file includes instructions so you can update your own file
without depending on a SA dev remembering to do it.
h2h
Axb
Re: .link TLD spammer haven?
Posted by Jesse Stroik <js...@ssec.wisc.edu>.
Martin (and others),
> As others have already said, URI body rules use a list of valid TLDs to
> help with recognising URIs embedded in body text and this list is
> currently hardcoded into SA.
Thank you for the explanation and the rule. I've put it in place and it
appears to work fine with my first set of tests.
> which I've tested fairly carefully. All the subrules except __MG_TLD1
> work exactly as I wanted them to. I can live with __MG_TLD1 not working
> until either a current SA maintenance version is released with an
> extended list of hardcoded TLDs or a version using a configurable list
> appears.
I suspect they'll allow a configurable list of TLDs going forward.
Best,
Jesse Stroik
Re: .link TLD spammer haven?
Posted by Martin Gregorie <ma...@gregorie.org>.
On Wed, 2014-10-22 at 13:40 -0500, Jesse Stroik wrote:
> I noticed URLs from the TLD .link aren't properly classified on my mail
> server. I wrote a simple URI rule to recognize that TLD which never
> matched. I wrote a similar body rule, which did properly match.
> Interestingly, I do see DNS queries going out for the URLs in question.
>
> This is sa 3.3.2-4 -- is it a known issue? The URL in question is on a
> single line and is easily pulled out with egrep and properly parsed with
> the body rule.
>
As others have already said, URI body rules use a list of valid TLDs to
help with recognising URIs embedded in body text and this list is
currently hardcoded into SA.
However, this doesn't affect any rules you might write to match domain
names in headers, so rules that use a regex to look for .link domains
in, for instance, Received or Reply-to headers will work as you'd expect
them to. So, If you don't want to mess around with replacing the
RegistrarBoundaries.pm file in your installation, you may care to write
a few rules that work with the headers and use them until a version of
SA with a configurable TLD list is released. I'm currently using this
meta-rule:
describe MG_LINK_TLD Messages from or containing a URL with the .link
TLD
uri __MG_LTD1 /\.link/i
header __MG_LTD2 From =~ /\.link>/
header __MG_LTD3 Received =~ /from.*\.link/
header __MG_LTD4 Return-Path =~ /\.link/
meta MG_LINK_TLD (__MG_LTD1 || __MG_LTD2 || __MG_LTD3 || __MG_LTD4)
score MG_LINK_TLD 7.5
which I've tested fairly carefully. All the subrules except __MG_TLD1
work exactly as I wanted them to. I can live with __MG_TLD1 not working
until either a current SA maintenance version is released with an
extended list of hardcoded TLDs or a version using a configurable list
appears.
HTH
Martin
Re: .link TLD spammer haven?
Posted by Joolee <in...@joolee.nl>.
You can try replacing your RegistrarBoundaries.pm file with the one from
trunk. It should be kept up-to-date with the latest TLD craze. As far as I
know, it hasn't been tested with 3.2.2 but should work nonetheless.
http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm?revision=1633582&view=markup
Kind regards,
Peter Overtoom
On 22 October 2014 20:46, Ken Bass <kb...@kenbass.com> wrote:
>
> On 10/22/2014 2:40 PM, Jesse Stroik wrote:
>
>> I noticed URLs from the TLD .link aren't properly classified on my mail
>> server. I wrote a simple URI rule to recognize that TLD which never
>> matched. I wrote a similar body rule, which did properly match.
>> Interestingly, I do see DNS queries going out for the URLs in question.
>>
>> This is sa 3.3.2-4 -- is it a known issue? The URL in question is on a
>> single line and is easily pulled out with egrep and properly parsed with
>> the body rule.
>>
>>
> 3.3.2 does not work with tlds that are not hardcoded into the software. I
> signed up on this list last week with the same complaint (.link and
> .website) are the latest spam havens.
> Apparently even 3.4 does not address this yet, but is being address in the
> future. Since I use Centos 7 which ships with 3.3.2, it creates a problem
> for me, meaning unless backported, I'm kinda stuck.
>
> What is a bit frustrating is that the URI rules will work for emails that
> are HTML encoded, but not for plain text emails. So I was pulling my hair
> out trying to figure out why my rules were working sometimes and not others.
>
Re: .link TLD spammer haven?
Posted by Ken Bass <kb...@kenbass.com>.
On 10/22/2014 2:40 PM, Jesse Stroik wrote:
> I noticed URLs from the TLD .link aren't properly classified on my
> mail server. I wrote a simple URI rule to recognize that TLD which
> never matched. I wrote a similar body rule, which did properly match.
> Interestingly, I do see DNS queries going out for the URLs in question.
>
> This is sa 3.3.2-4 -- is it a known issue? The URL in question is on a
> single line and is easily pulled out with egrep and properly parsed
> with the body rule.
>
3.3.2 does not work with tlds that are not hardcoded into the software.
I signed up on this list last week with the same complaint (.link and
.website) are the latest spam havens.
Apparently even 3.4 does not address this yet, but is being address in
the future. Since I use Centos 7 which ships with 3.3.2, it creates a
problem for me, meaning unless backported, I'm kinda stuck.
What is a bit frustrating is that the URI rules will work for emails
that are HTML encoded, but not for plain text emails. So I was pulling
my hair out trying to figure out why my rules were working sometimes and
not others.
Re: .link TLD spammer haven?
Posted by Jesse Stroik <js...@ssec.wisc.edu>.
I noticed URLs from the TLD .link aren't properly classified on my mail
server. I wrote a simple URI rule to recognize that TLD which never
matched. I wrote a similar body rule, which did properly match.
Interestingly, I do see DNS queries going out for the URLs in question.
This is sa 3.3.2-4 -- is it a known issue? The URL in question is on a
single line and is easily pulled out with egrep and properly parsed with
the body rule.
Best,
Jesse Stroik
On 10/13/2014 2:53 PM, Dave Funk wrote:
> On Mon, 13 Oct 2014, Philip Prindeville wrote:
>
>> Every connection I’ve gotten from a hostname resolving to *.link or
>> saying helo *.link has been spam (I block the connections with
>> MIMEDefang).
>>
>> Has anyone actually seen a legitimate email from a host in the .link TLD?
>>
>> I’ve seen (last week alone):
>>
>> bgo.blc-onlineconsumer140.link
>> ratio.allgiftcardsonlinefriendly.link
>> ratio.autodealersstarted.link
> [snip..]
>
>> Is it worth having that triggers on the relay’s hostname being *.link?
>>
>> Also, I noticed that every message we saw was missing a Received: header…
>>
>> -Philip
>
> I'll second that and add a similar comment about ".link" URLs inside the
> message. Last week I created a uri rule to fire on any ".link" hosted URL
> and so far havn't seen a single FP.
>
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Cathryn Mataga <ca...@junglevision.com>.
> ???
>
> Are you using imap to fetch your mail?
Thanks guys. Yes I am using imap. What I have is a .procmailrc that
forwards to meganspam. That's how this email got to meganspam. Is
spamassasin is running twice? Once going to megan@ and then at
meganspam@. What I did then is I fished the lost email out of
'meganspam' and and posted it here.
[root@ecuador megan]# cat .procmailrc
:0
* ^Subject:.*\[SPAM\]*
!meganspam@junglevision.com
:0
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by jdebert <jd...@garlic.com>.
On Thu, 16 Oct 2014 22:37:20 -0700
Cathryn Mataga <ca...@junglevision.com> wrote:
> The score is only 1.9, 3.5 required. What's going on here?
>
>
> From megan@ecuador.junglevision.com Mon Oct 13 08:38:09 2014
> Return-Path: <me...@ecuador.junglevision.com>
> X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
> ecuador.junglevision.com
> X-Spam-Level: *
> X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED,
> EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,
> URIBL_BLOCKED autolearn=disabled version=3.3.2
> Received: from ecuador.junglevision.com (localhost [127.0.0.1])
> by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id
> s9DFc8B7015308
> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384
> bits=256 verify=NO)
> for <me...@junglevision.com>; Mon, 13 Oct 2014 08:38:08
> -0700 Received: (from megan@localhost)
> by ecuador.junglevision.com (8.14.7/8.14.7/Submit) id
> s9DFc8xV015307
> for meganspam@junglevision.com; Mon, 13 Oct 2014 08:38:08
> -0700
^^^^^^^^
Recipient changed
Received: from egssmtp03.att.com (egssmtp03.att.com
> [144.160.128.152]) by ecuador.junglevision.com (8.14.7/8.14.7) with
> ESMTP id s9DFc5xN015302
> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
> verify=OK) for <me...@junglevision.com>; Mon, 13 Oct 2014 08:38:06
> -0700
Original recipient -- up to here.
Received: from uspedd06.edc.cingular.net
> (uspedd06.edc.cingular.net [135.214.228.40])
> by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id
> s9DFc46P014887
> for <me...@junglevision.com>; Mon, 13 Oct 2014 08:38:05 -0700
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
> d=amcustomercare.att-mail.com; s=egs03; t=1413214685;
> bh=MI7iSFEx0e8sM2n1cEp/PA3RpmsCaSIBkzWhOYJfYAA=;
> h=Message-ID:Date:From:To:Subject:Mime-Version:Content-Type:
> Content-Transfer-Encoding;
> b=CYX9YX0nPomkMgc9QVja839EteJAXDIlKj0PGU7FS6Na0Bbe2MKs02M/tElklPs4H
> xkFLgTFYcep3bVF5BvPXbx4GTTTfG8t2SRph/JzCEMIkZUGCyjVnB+l507IiU/8qwZ
> D318VRDQoTPpXolVQMvP7EWBvn63ZKf49zG/Lh5JnhVqYYxcMyS5XVfJR9VRgt/Y+v
> lt4nkGSI0L+bf76ajwYTS6bERuSXRkwn7LsqYZkLRzBVbseQVK2oMFjV7pABS3Ru7d
> B2qDr9tjTuGnAhVrp8dloyU+fBVRc4jcj8Fas1FqgcoXoYFfIgqR2dQNkeKpYl+qRi
> GvEd3zXt9+ajw==
> Message-ID:
> <15...@uspedd06.edc.cingular.net>
^^^^^^^^
???
Are you using imap to fetch your mail?
> Date: Mon, 13 Oct 2014 10:38:04 -0500 (CDT)
> From: AT&T Customer Care <ic...@amcustomercare.att-mail.com>
> To: megan@junglevision.com
> Subject: [SPAM] Your AT&T wireless bill is ready to view
^^^^^^
Fairly sure that this is not from spamassassin.
It appears the original recipient is megan@mumble but the address has
been rewritten or forwarded to meganspam@mumble.
It's only a guess but it appears that some server upstream has changed
the subject for you. Have a look at your mail logs to see if the subject
came into your server that way. If so, there's probably nothing you can
do to stop it. You can however, depending on your server, rewrite
subjects to remove such uselessly helpful edits.
And perhaps an upstream server has not properly implemented DKIM to
authenticate this message or has improperly modified it resulting in it
being marked as spam? DKIM auth apparently isn't too easy to get right.
jd
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sat, 2014-10-25 at 20:06 -0700, Cathryn Mataga wrote:
>
> Okay, here's another header. Shows X-Xpam-Status as no.
>
> In local.cf I changed to this, just to be sure.
>
> rewrite_header Subject [SPAM][JUNGLEVISION SPAM CHECK]
> X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
> ecuador.junglevision.com
> X-Spam-Level: *
> X-Spam-Status: No, score=1.5 required=3.5 tests=BAYES_50,HTML_MESSAGE,
> MIME_HTML_ONLY,MIME_QP_LONG_LINE autolearn=disabled version=3.3.2
> Subject: [SPAM][JUNGLEVISION SPAM CHECK] Confirmation of Order Number
> 684588 * Please Do Not Reply To This Email *
Somehow, you are passing messages to SA twice.
First one classifies it spam and rewrites the Subject. Second run
doesn't. Added headers, content wrapping, or most likely re-transmission
from trusted networks makes the second run fail.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by John Hardin <jh...@impsec.org>.
On Mon, 27 Oct 2014, John Hardin wrote:
> On Mon, 27 Oct 2014, jdebert wrote:
>
>> On Sun, 26 Oct 2014 13:28:12 -0700 (PDT)
>> John Hardin <jh...@impsec.org> wrote:
>>
>> >
>> > That's an SA directive. It says "if the message scores spammy,
>> > prepend '[SPAM][JUNGLEVISION SPAM CHECK]' to the Subject header."
>>
>> Ah. Missing some messages here.
>>
>> It does appear that sa is the culprit but why it's doing it is not
>> evident. There's still not enough data. Perhaps turning up debugging
>> would be helpful?
>
> The apparent culprit is a procmail rule that explicitly passes a message
> through the mail system again. The message is being scanned twice. If she can
> either deliver to a local mailbox rather than forwarding to an email address,
oops. That should be "deliver to a local mail folder".
> or modify the procmail rule that calls SA to ignore messages that have
> already passed through the server once, I think the problem would go away.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the Fates notice those who buy chainsaws...
-- www.darwinawards.com
-----------------------------------------------------------------------
4 days until Halloween
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Mon, 2014-10-27 at 20:19 -0700, jdebert wrote:
> On Mon, 27 Oct 2014 15:45:03 -0700 (PDT)
> John Hardin <jh...@impsec.org> wrote:
> > The apparent culprit is a procmail rule that explicitly passes a
> > message through the mail system again. The message is being scanned
> > twice. If she can either deliver to a local mailbox rather than
> > forwarding to an email address, or modify the procmail rule that
> > calls SA to ignore messages that have already passed through the
> > server once, I think the problem would go away.
>
> It looks as if it's the global procmailrc that always puts all mail,
> even mail between local users through spamassassin. However, I don't
> see how going through spamassassin again will modify the header. It's
It is not the second run that modifies the header. It's the first one.
With the second run classifying the mail as not-spam.
> already modified before the user procmail rule sees it. Something
> appears to be causing the first run of sa to modify the header
> unconditionally. If global procmail actually does the first run.
A system-wide procmail recipe feeds mail to SA.
Then there's a user procmail recipe that forwards mail with a Subject
matching /SPAM/ to another "dedicated spam dump" address with the same
domain, which ends up being delivered to that domain's MX. The same SMTP
server. Now re-processing the original mail (possibly wrapped in an
RFC822 attachment by SA), feeding it to SA due to the system-wide
procmail recipe...
On that second run, the message previously classified spam does not
exceed the threshold. Thus the X-Spam-Status of no, overriding the
previous Status header which is being ignored by SA anyway.
Result: Subject header rewritten by SA, despite final (delivery time)
spam status of no. This thread's Subject.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by jdebert <jd...@garlic.com>.
On Mon, 27 Oct 2014 15:45:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
> On Mon, 27 Oct 2014, jdebert wrote:
>
> > It does appear that sa is the culprit but why it's doing it is not
> > evident. There's still not enough data. Perhaps turning up debugging
> > would be helpful?
>
> The apparent culprit is a procmail rule that explicitly passes a
> message through the mail system again. The message is being scanned
> twice. If she can either deliver to a local mailbox rather than
> forwarding to an email address, or modify the procmail rule that
> calls SA to ignore messages that have already passed through the
> server once, I think the problem would go away.
>
It looks as if it's the global procmailrc that always puts all mail,
even mail between local users through spamassassin. However, I don't
see how going through spamassassin again will modify the header. It's
already modified before the user procmail rule sees it. Something
appears to be causing the first run of sa to modify the header
unconditionally. If global procmail actually does the first run.
jd
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by John Hardin <jh...@impsec.org>.
On Mon, 27 Oct 2014, jdebert wrote:
> On Sun, 26 Oct 2014 13:28:12 -0700 (PDT)
> John Hardin <jh...@impsec.org> wrote:
>
>>
>> That's an SA directive. It says "if the message scores spammy,
>> prepend '[SPAM][JUNGLEVISION SPAM CHECK]' to the Subject header."
>
> Ah. Missing some messages here.
>
> It does appear that sa is the culprit but why it's doing it is not
> evident. There's still not enough data. Perhaps turning up debugging
> would be helpful?
The apparent culprit is a procmail rule that explicitly passes a message
through the mail system again. The message is being scanned twice. If she
can either deliver to a local mailbox rather than forwarding to an email
address, or modify the procmail rule that calls SA to ignore messages that
have already passed through the server once, I think the problem would go
away.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the Fates notice those who buy chainsaws...
-- www.darwinawards.com
-----------------------------------------------------------------------
4 days until Halloween
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by jdebert <jd...@garlic.com>.
On Sun, 26 Oct 2014 13:28:12 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
>
> That's an SA directive. It says "if the message scores spammy,
> prepend '[SPAM][JUNGLEVISION SPAM CHECK]' to the Subject header."
Ah. Missing some messages here.
It does appear that sa is the culprit but why it's doing it is not
evident. There's still not enough data. Perhaps turning up debugging
would be helpful?
jd
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by John Hardin <jh...@impsec.org>.
On Sun, 26 Oct 2014, jdebert wrote:
> On Sat, 25 Oct 2014 20:06:00 -0700
> Cathryn Mataga <ca...@junglevision.com> wrote:
>>
>> Okay, here's another header. Shows X-Xpam-Status as no.
>>
>> In local.cf I changed to this, just to be sure.
>>
>> rewrite_header Subject [SPAM][JUNGLEVISION SPAM CHECK]
>
> Not familiar with how sendmail rewrites headers. Is this supposed to
> replace [SPAM] with [JUNGLEVISION SPAM CHECK]? replace the subject with
> [SPAM][JUNGLEVISION SPAM CHECK] or ...?
That's an SA directive. It says "if the message scores spammy, prepend
'[SPAM][JUNGLEVISION SPAM CHECK]' to the Subject header."
> How does your sa modify the subject? Is it the default
> ****SPAM(%score)****?
The rewrite_header.
> It looks as if the message is delivered to megan and then something
> is resubmitting the message to sendmail. Are you using procmail to
> forward messages containing SPAM to meganspam? Could that be why
> sendmail sees the message twice?
Yes. She posted a procmailrc snippet that does exactly that.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the Fates notice those who buy chainsaws...
-- www.darwinawards.com
-----------------------------------------------------------------------
5 days until Halloween
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by jdebert <jd...@garlic.com>.
On Sat, 25 Oct 2014 20:06:00 -0700
Cathryn Mataga <ca...@junglevision.com> wrote:
>
>
> Okay, here's another header. Shows X-Xpam-Status as no.
>
> In local.cf I changed to this, just to be sure.
>
> rewrite_header Subject [SPAM][JUNGLEVISION SPAM CHECK]
Not familiar with how sendmail rewrites headers. Is this supposed to
replace [SPAM] with [JUNGLEVISION SPAM CHECK]? replace the subject with
[SPAM][JUNGLEVISION SPAM CHECK] or ...?
How does your sa modify the subject? Is it the default
****SPAM(%score)****?
It looks as if the message is delivered to megan and then something
is resubmitting the message to sendmail. Are you using procmail to
forward messages containing SPAM to meganspam? Could that be why
sendmail sees the message twice?
Are you using milters with sendmail? How hard would it be to disable
them one by one and inject test messages with [SPAM] in the subject?
What if you turned up spamassassin's and sendmail's debugging? I wonder
if that would log the Subject header as it receives the incoming message
and handles it. It could tell you if the message is received with [SPAM]
already in the header or where [SPAM] is being inserted before delivery.
jd
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by John Hardin <jh...@impsec.org>.
On Sat, 25 Oct 2014, Cathryn Mataga wrote:
> On 10/25/2014 9:29 PM, John Hardin wrote:
>> On Sat, 25 Oct 2014, Cathryn Mataga wrote:
>>
>> > Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by
>> > ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2o1ZZ026032
>> > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
>> > verify=NO) for <me...@junglevision.com>; Fri, 24 Oct 2014
>> > 19:50:01 -0700
>> > Received: (from megan@localhost) by ecuador.junglevision.com
>> > (8.14.7/8.14.7/Submit) id s9P2o1dN026031 for
>> > meganspam@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700
>>
>> Why is the message hitting ecuador.junglevision.com twice?
>>
>
> Would this do it? Maybe it's just failing on the initial spam check and then
> .procmailrc meganspam checks again for some reason?
>
> [root@ecuador megan]# cat .procmailrc
> : 0
> * ^Subject:.*\[SPAM\]*
> !meganspam@junglevision.com
Yes, that would do it.
I suspect what you really want here is to save the spam to a mail folder
rather than forwarding it to a different user, which will send it through
the mail system again.
> [root@ecuador spamassassin]# cat spamassassin-default.rc
> # send mail through spamassassin
> : 0fw
> | /usr/bin/spamassassin
You probably should be using spamc there rather than firing off a fresh
new spamassassin for each message, which re-parses all of the rules from
scratch every time.
You also might want to put an exclusion in there for messages having a
Received: from ecuador.junglevision.com (localhost [127.0.0.1])
header so that you don't scan messages twice.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
877 days since the first successful private support mission to ISS (SpaceX)
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Cathryn Mataga <ca...@junglevision.com>.
On 10/25/2014 9:29 PM, John Hardin wrote:
> On Sat, 25 Oct 2014, Cathryn Mataga wrote:
>
>> Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by
>> ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2o1ZZ026032
>> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
>> verify=NO) for <me...@junglevision.com>; Fri, 24 Oct 2014
>> 19:50:01 -0700
>> Received: (from megan@localhost) by ecuador.junglevision.com
>> (8.14.7/8.14.7/Submit) id s9P2o1dN026031 for
>> meganspam@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700
>
> Why is the message hitting ecuador.junglevision.com twice?
>
Would this do it? Maybe it's just failing on the initial spam check and
then .procmailrc meganspam checks again for some reason?
[root@ecuador megan]# cat .procmailrc
:0
* ^Subject:.*\[SPAM\]*
!meganspam@junglevision.com
[root@ecuador etc]# pwd
/etc
[root@ecuador etc]# cat procmailrc
DROPPRIVS=yes
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
Then I have.
[root@ecuador spamassassin]# cat spamassassin-default.rc
# send mail through spamassassin
:0fw
| /usr/bin/spamassassin
Don't believe there's anything creative happening here, right? Am I
missing something obvious?
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by John Hardin <jh...@impsec.org>.
On Sat, 25 Oct 2014, Cathryn Mataga wrote:
> Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by
> ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2o1ZZ026032
> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
> verify=NO) for <me...@junglevision.com>; Fri, 24 Oct 2014
> 19:50:01 -0700
> Received: (from megan@localhost) by ecuador.junglevision.com
> (8.14.7/8.14.7/Submit) id s9P2o1dN026031 for
> meganspam@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700
Why is the message hitting ecuador.junglevision.com twice?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
877 days since the first successful private support mission to ISS (SpaceX)
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Cathryn Mataga <ca...@junglevision.com>.
Okay, here's another header. Shows X-Xpam-Status as no.
In local.cf I changed to this, just to be sure.
rewrite_header Subject [SPAM][JUNGLEVISION SPAM CHECK]
Return-Path: <me...@ecuador.junglevision.com>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
ecuador.junglevision.com
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=3.5 tests=BAYES_50,HTML_MESSAGE,
MIME_HTML_ONLY,MIME_QP_LONG_LINE autolearn=disabled version=3.3.2
Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by
ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2o1ZZ026032
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
verify=NO) for <me...@junglevision.com>; Fri, 24 Oct 2014 19:50:01 -0700
Received: (from megan@localhost) by ecuador.junglevision.com
(8.14.7/8.14.7/Submit) id s9P2o1dN026031 for meganspam@junglevision.com;
Fri, 24 Oct 2014 19:50:01 -0700
Received: from outbound.audienceview.com (outbound.audienceview.com
[65.110.162.244]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP
id s9P2nvn2026026 for <me...@junglevision.com>; Fri, 24 Oct 2014
19:49:58 -0700
Received: from AVWEB98 ([127.0.0.1]) by outbound.audienceview.com with
Microsoft SMTPSVC(7.5.7601.17514); Fri, 24 Oct 2014 19:49:57 -0700
From: tickets@shnsf.com
To: megan@junglevision.com
Subject: [SPAM][JUNGLEVISION SPAM CHECK] Confirmation of Order Number
684588 * Please Do Not Reply To This Email *
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="39c73e15-d5dd-4652-bd83-b7c65171173c"
Date: Fri, 24 Oct 2014 19:49:57 -0700
Message-ID: <1C...@shnsf.com>
X-OriginalArrivalTime: 25 Oct 2014 02:49:57.0206 (UTC)
FILETIME=[5CA4A760:01CFEFFE]
X-Spam-Prev-Subject: Confirmation of Order Number 684588 * Please Do
Not Reply To This Email *
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Cathryn Mataga <ca...@junglevision.com>.
On 10/20/14, 9:46 AM, jdebert wrote:
> On Mon, 20 Oct 2014 12:39:57 +0200
> Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>
>> On 17.10.14 10:08, jdebert wrote:
>>> Will URIBL_BLOCKED cause [SPAM] to be inserted into Subject?
>>
>> no, it will more likely cause [SPAM] _not_ to be inserted, because it
>> wouldn't be detected.
>
> Good. Had me worried a bit there. (^_^)
>
>>
>>> Also, doesn't sa insert something else a bit different? Isn't it
>>> likely that someone else inserted that before the OP's server ever
>>> saw it?
>>
>> If SA inserts anything to Subject: and what it is, depends only on SA
>> configuration. It's the "rewrite_header" configuration directive.
>>
>
> Of course. I was thinking at the time that some other spam filter/tagger
> that used that by default might have done this. After posting, realised
> that the config would have to be changed for that. Forgot to ask if it
> was the case.
>
> I recall some cases in the past where spam filtering setups, such as
> those for "antispam" appliances did such things by default without
> adding any headers. I suspected this might be the case here. Too many
> possibilities, too little data.
>
What I'll do then is change the inserted message to something else.
Just to verify this. I did manage to get rid of the warning from the
dnsdbl list. But I can pull this and try again too.
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by jdebert <jd...@garlic.com>.
On Mon, 20 Oct 2014 12:39:57 +0200
Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
> On 17.10.14 10:08, jdebert wrote:
> >Will URIBL_BLOCKED cause [SPAM] to be inserted into Subject?
>
> no, it will more likely cause [SPAM] _not_ to be inserted, because it
> wouldn't be detected.
Good. Had me worried a bit there. (^_^)
>
> >Also, doesn't sa insert something else a bit different? Isn't it
> >likely that someone else inserted that before the OP's server ever
> >saw it?
>
> If SA inserts anything to Subject: and what it is, depends only on SA
> configuration. It's the "rewrite_header" configuration directive.
>
Of course. I was thinking at the time that some other spam filter/tagger
that used that by default might have done this. After posting, realised
that the config would have to be changed for that. Forgot to ask if it
was the case.
I recall some cases in the past where spam filtering setups, such as
those for "antispam" appliances did such things by default without
adding any headers. I suspected this might be the case here. Too many
possibilities, too little data.
jd
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Fri, 17 Oct 2014 12:13:49 +0100
>Martin Gregorie <ma...@gregorie.org> wrote:
>
>> On Thu, 2014-10-16 at 22:37 -0700, Cathryn Mataga wrote:
>> > The score is only 1.9, 3.5 required. What's going on here?
>> >
>> > X-Spam-Status: No, score=1.9 required=3.5
>> > tests=BAYES_50,DKIM_SIGNED,
>> > EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,
>> > URIBL_BLOCKED autolearn=disabled version=3.3.2
>> >
>> URIBL_BLOCKED usually means that you've exceeded the daily free use
>> limit on URIBL queries.
On 17.10.14 10:08, jdebert wrote:
>Will URIBL_BLOCKED cause [SPAM] to be inserted into Subject?
no, it will more likely cause [SPAM] _not_ to be inserted, because it
wouldn't be detected.
>Also, doesn't sa insert something else a bit different? Isn't it
>likely that someone else inserted that before the OP's server ever
>saw it?
If SA inserts anything to Subject: and what it is, depends only on SA
configuration. It's the "rewrite_header" configuration directive.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
One OS to rule them all, One OS to find them,
One OS to bring them all and into darkness bind them
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by jdebert <jd...@garlic.com>.
On Fri, 17 Oct 2014 12:13:49 +0100
Martin Gregorie <ma...@gregorie.org> wrote:
> On Thu, 2014-10-16 at 22:37 -0700, Cathryn Mataga wrote:
> > The score is only 1.9, 3.5 required. What's going on here?
> >
> > X-Spam-Status: No, score=1.9 required=3.5
> > tests=BAYES_50,DKIM_SIGNED,
> > EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,
> > URIBL_BLOCKED autolearn=disabled version=3.3.2
> >
> URIBL_BLOCKED usually means that you've exceeded the daily free use
> limit on URIBL queries.
>
Will URIBL_BLOCKED cause [SPAM] to be inserted into Subject?
Also, doesn't sa insert something else a bit different? Isn't it
likely that someone else inserted that before the OP's server ever
saw it?
jd
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.10.2014 um 18:34 schrieb Cathryn Mataga:
> On 10/17/14, 9:20 AM, Matus UHLAR - fantomas wrote:
>>> On 10/17/14, 4:13 AM, Martin Gregorie wrote:
>>>> URIBL_BLOCKED usually means that you've exceeded the daily free use
>>>> limit on URIBL queries.
>>>>
>>>> What DNS server are you using? If its a public one belonging to your
>>>> ISP
>>>> or Google, that explains why the blacklists think you exceeded the free
>>>> limit: they count queries per DNS server since that's what sends the
>>>> queries to them. To avoid this you should be running a private,
>>>> non-forwarding DNS server.
>>
>> On 17.10.14 09:17, Cathryn Mataga wrote:
>>> I run DNS on my network. I think it should be caching, but maybe
>>> that's broken?
>>
>> the question is if it forwards requests to other DNS servers (probably
>> your
>> ISPs) or if you process thousands mails daily...
>>
>
> I should check. I do well less than 100 legitimate emails a day, but I
> think I might be pulling in thousand(s)+ of spam
if your dns server does forwarding it's worthless because the result is
the same: one central ISP DNS with always the same IP is asking the
blacklist servers, get blocked and hence gives you that back
the legitimate don't count, the DNS requests happen anyways
Connections: 251066
Delivered: 42579
Blocked: 208487
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by Martin Gregorie <ma...@gregorie.org>.
On Fri, 2014-10-17 at 09:34 -0700, Cathryn Mataga wrote:
> I should check. I do well less than 100 legitimate emails a day, but I
> think I might be pulling in thousand(s)+ of spam.
>
1) check that your DNS isn't forwarding requests to another DNS.
Its the 'forward' statement(s) in your DNS configuration.
2) If you haven't got an SPF record for your domain, set one up.
It's not much use for detecting spam, but will stop you
receiving backscatter (spam sent to other domains' non-existent
users with your address forged as the sender.
Use http://www.kitterman.com/spf/validate.html to validate
your SPF record when you've set one up.
3) consider implementing greylisting. When my ISP implemented it,
my spam:ham ratio went from 80:20 to 20:80 overnight (I use
getmail to retrieve e-mail from a mailbox in my ISP's mail server).
Martin
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Cathryn Mataga <ca...@junglevision.com>.
On 10/17/14, 9:20 AM, Matus UHLAR - fantomas wrote:
>> On 10/17/14, 4:13 AM, Martin Gregorie wrote:
>>> URIBL_BLOCKED usually means that you've exceeded the daily free use
>>> limit on URIBL queries.
>>>
>>> What DNS server are you using? If its a public one belonging to your ISP
>>> or Google, that explains why the blacklists think you exceeded the free
>>> limit: they count queries per DNS server since that's what sends the
>>> queries to them. To avoid this you should be running a private,
>>> non-forwarding DNS server.
>
> On 17.10.14 09:17, Cathryn Mataga wrote:
>> I run DNS on my network. I think it should be caching, but maybe
>> that's broken?
>
> the question is if it forwards requests to other DNS servers (probably your
> ISPs) or if you process thousands mails daily...
>
I should check. I do well less than 100 legitimate emails a day, but I
think I might be pulling in thousand(s)+ of spam.
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 10/17/14, 4:13 AM, Martin Gregorie wrote:
>>URIBL_BLOCKED usually means that you've exceeded the daily free use
>>limit on URIBL queries.
>>
>>What DNS server are you using? If its a public one belonging to your ISP
>>or Google, that explains why the blacklists think you exceeded the free
>>limit: they count queries per DNS server since that's what sends the
>>queries to them. To avoid this you should be running a private,
>>non-forwarding DNS server.
On 17.10.14 09:17, Cathryn Mataga wrote:
>I run DNS on my network. I think it should be caching, but maybe
>that's broken?
the question is if it forwards requests to other DNS servers (probably your
ISPs) or if you process thousands mails daily...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton
Re: How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Cathryn Mataga <ca...@junglevision.com>.
On 10/17/14, 4:13 AM, Martin Gregorie wrote:
> On Thu, 2014-10-16 at 22:37 -0700, Cathryn Mataga wrote:
>> The score is only 1.9, 3.5 required. What's going on here?
>>
>> X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED,
>> EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,
>> URIBL_BLOCKED autolearn=disabled version=3.3.2
>>
> URIBL_BLOCKED usually means that you've exceeded the daily free use
> limit on URIBL queries.
>
> What DNS server are you using? If its a public one belonging to your ISP
> or Google, that explains why the blacklists think you exceeded the free
> limit: they count queries per DNS server since that's what sends the
> queries to them. To avoid this you should be running a private,
> non-forwarding DNS server.
I run DNS on my network. I think it should be caching, but maybe that's
broken? The thing is, I've had this email at this domain name for
over a decade now, no, maybe to the mid 90's? Maybe it's just that I
get a HUGE amount of spam. It is a spectacular flow to watch it all go
through here.
I did disable the dns black whole servers seeing this. So maybe my
first instinct on this was correct. We'll see if it gets better.
>
>
> Martin
>
>
Re: How is it that my X-Spam-Status is no, but my header gets
marked with
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2014-10-16 at 22:37 -0700, Cathryn Mataga wrote:
> The score is only 1.9, 3.5 required. What's going on here?
>
> X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED,
> EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,
> URIBL_BLOCKED autolearn=disabled version=3.3.2
>
URIBL_BLOCKED usually means that you've exceeded the daily free use
limit on URIBL queries.
What DNS server are you using? If its a public one belonging to your ISP
or Google, that explains why the blacklists think you exceeded the free
limit: they count queries per DNS server since that's what sends the
queries to them. To avoid this you should be running a private,
non-forwarding DNS server.
Martin
How is it that my X-Spam-Status is no, but my header gets marked
with
Posted by Cathryn Mataga <ca...@junglevision.com>.
The score is only 1.9, 3.5 required. What's going on here?
From megan@ecuador.junglevision.com Mon Oct 13 08:38:09 2014
Return-Path: <me...@ecuador.junglevision.com>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
ecuador.junglevision.com
X-Spam-Level: *
X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED,
EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,
URIBL_BLOCKED autolearn=disabled version=3.3.2
Received: from ecuador.junglevision.com (localhost [127.0.0.1])
by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id
s9DFc8B7015308
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
verify=NO)
for <me...@junglevision.com>; Mon, 13 Oct 2014 08:38:08 -0700
Received: (from megan@localhost)
by ecuador.junglevision.com (8.14.7/8.14.7/Submit) id
s9DFc8xV015307
for meganspam@junglevision.com; Mon, 13 Oct 2014 08:38:08 -0700
Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152])
by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id
s9DFc5xN015302
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for <me...@junglevision.com>; Mon, 13 Oct 2014 08:38:06 -0700
Received: from uspedd06.edc.cingular.net (uspedd06.edc.cingular.net
[135.214.228.40])
by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id
s9DFc46P014887
for <me...@junglevision.com>; Mon, 13 Oct 2014 08:38:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=amcustomercare.att-mail.com; s=egs03; t=1413214685;
bh=MI7iSFEx0e8sM2n1cEp/PA3RpmsCaSIBkzWhOYJfYAA=;
h=Message-ID:Date:From:To:Subject:Mime-Version:Content-Type:
Content-Transfer-Encoding;
b=CYX9YX0nPomkMgc9QVja839EteJAXDIlKj0PGU7FS6Na0Bbe2MKs02M/tElklPs4H
xkFLgTFYcep3bVF5BvPXbx4GTTTfG8t2SRph/JzCEMIkZUGCyjVnB+l507IiU/8qwZ
D318VRDQoTPpXolVQMvP7EWBvn63ZKf49zG/Lh5JnhVqYYxcMyS5XVfJR9VRgt/Y+v
lt4nkGSI0L+bf76ajwYTS6bERuSXRkwn7LsqYZkLRzBVbseQVK2oMFjV7pABS3Ru7d
B2qDr9tjTuGnAhVrp8dloyU+fBVRc4jcj8Fas1FqgcoXoYFfIgqR2dQNkeKpYl+qRi
GvEd3zXt9+ajw==
Message-ID:
<15...@uspedd06.edc.cingular.net>
Date: Mon, 13 Oct 2014 10:38:04 -0500 (CDT)
From: AT&T Customer Care <ic...@amcustomercare.att-mail.com>
To: megan@junglevision.com
Subject: [SPAM] Your AT&T wireless bill is ready to view
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: 7bit
AT&T: OLAMBRN-284864694
X-Spam-Prev-Subject: Your AT&T wireless bill is ready to view
X-UID: 682695
Status: O
Content-Length: 12557
Re: .link TLD spammer haven?
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Mon, 13 Oct 2014, Philip Prindeville wrote:
> Every connection I’ve gotten from a hostname resolving to *.link or saying helo *.link has been spam (I block the connections with MIMEDefang).
>
> Has anyone actually seen a legitimate email from a host in the .link TLD?
>
> I’ve seen (last week alone):
>
> bgo.blc-onlineconsumer140.link
> ratio.allgiftcardsonlinefriendly.link
> ratio.autodealersstarted.link
[snip..]
> Is it worth having that triggers on the relay’s hostname being *.link?
>
> Also, I noticed that every message we saw was missing a Received: header…
>
> -Philip
I'll second that and add a similar comment about ".link" URLs inside the
message. Last week I created a uri rule to fire on any ".link" hosted URL
and so far havn't seen a single FP.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{