You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ian Zimmerman <it...@primate.net> on 2017/02/07 00:52:19 UTC
New type of monstrosity
Last couple of weeks I saw some messages whose entire contents is in the
Subject. They have both a text/plain and text/html part but both are
empty (in the case of html, there is some markup but no character
data). The Subject is maybe 400 or 500 chars long.
Needless to say, this is a 100% spam trait, but some escaped.
Is there already a rule somewhere to deal with this? (not among the
ones bundled with SA, I don't think)
If I'm writing my own, is the naive way to match the Subject going to
work? I'm asking mostly because the header is properly split and
continued around 60 character bonudaries. That is, does SA join
continued lines before matching?
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: New type of monstrosity
Posted by RW <rw...@googlemail.com>.
On Tue, 07 Feb 2017 02:57:06 -0500
Ruga wrote:
> The spample would never make it to our SA. It would be rejected
> upstream for at least two reasons:
>
> > To: undisclosed recipients: ;
>
>
> The To header is not RFC compliant.The Subject header exceeds the
> maximum line length,
You can reject based on normal usage, but it is RFC compliant.
"Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF."
The 78 character "SHOULD" limit is only there to make the content more
readable on 80-column terminals.
Re: New type of monstrosity
Posted by "@lbutlr" <kr...@kreme.com>.
On Feb 7, 2017, at 12:57 AM, Ruga <ru...@protonmail.com> wrote:
> The spample would never make it to our SA. It would be rejected upstream for at least two reasons:
>
> > To: undisclosed recipients: ;
> The To header is not RFC compliant.
Where do you get that idea? “Undisclosed recipient: ;” is a group address.
RFS 2822 A.1.3:
From: Pete <pe...@silly.example>
To: A Group:Chris Jones <c...@a.test>,joe@where.test,John <jd...@one.test>;
Cc: Undisclosed recipients:;
Date: Thu, 13 Feb 1969 23:32:54 -0330
Message-ID: <te...@silly.example>
Testing.
----
In this message, the "To:" field has a single group recipient named A
Group which contains 3 addresses, and a "Cc:" field with an empty
group recipient named Undisclosed recipients.
Please note that in the example given the To field contains a SINGLE group recipient.
Also, in 3.4: " An address may either be an individual mailbox, or a group of mailboxes.”
and in 3.6.3: "The destination fields of a message consist of three possible fields, each of the same form: The field name, which is either "To", "Cc", or "Bcc", followed by a comma-separated list of one or more addresses (either mailbox or group syntax).”
So, yes, Undiscloded recipients: ; is absolutely valid.
> The Subject header exceeds the maximum line length, being another RFC constraints.
2.1.1: "There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.”
While I am here, ‘+’ is a perfectly valid character in the user portion of an email, a fact that seems to elude many email “admins”.
--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.
Re: New type of monstrosity / RFC Pedantry
Posted by John Hardin <jh...@impsec.org>.
On Thu, 9 Feb 2017, Groach wrote:
> https://imgs.xkcd.com/comics/duty_calls.png
>
> Come on chaps and chapesses. Nothing is going to be concluded between you
> too. And having the last word doesnt make one better than the others (and it
> still doesnt make you right).
>
> Just agree that neither of you is going to convince the other or leave them
> happy.
>
> Life is short....and this is silly.
Agreed.
RFC compliance is relevant to this list only insofar as it is a useful
spam sign. SA is *not* an RFC-compliance-verification tool.
Whether or not "undisclosed recipients:" is valid per RFCs is off topic
for this list, and is engendering a lot of ill will and increasingly
personal attacks.
Ruga: if you can show that "undisclosed recipients:" occurs *significantly
more often* in spam than in ham, the topic is germane to this list.
Warning to all: the banhammer is being warmed up. Please, everyone, just
stop now, before it's too late.
--
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
-----------------------------------------------------------------------
Usually Microsoft doesn't develop products, we buy products.
-- Arno Edelmann, Microsoft product manager
-----------------------------------------------------------------------
3 days until Abraham Lincoln's and Charles Darwin's 208th Birthdays
Re: New type of monstrosity
Posted by Groach <gr...@yahoo.com>.
https://imgs.xkcd.com/comics/duty_calls.png
Come on chaps and chapesses. Nothing is going to be concluded between
you too. And having the last word doesnt make one better than the
others (and it still doesnt make you right).
Just agree that neither of you is going to convince the other or leave
them happy.
Life is short....and this is silly.
On 09/02/2017 15:26, Dianne Skoll wrote:
> Ruga <ru...@protonmail.com> wrote:
>
>> RFC-822 is the e-mail standard, without "group addresses". What we do
>> complies with the standard.
> You are wrong. Wrong, wrong, wrong, wrong.
>
> Take a look at RFC-822: https://www.ietf.org/rfc/rfc0822.txt
>
> Go to Section 6. ADDRESS SPECIFICATION. Look at Section 6.1.
>
> Here's a copy/paste:
>
> address = mailbox ; one addressee
> / group ; named list
>
> group = phrase ":" [#mailbox] ";"
>
>
> Oh look! The group address specification! In RFC 822! Amazing!
>
> Ruga, my dear fellow, (or lady... I can't tell), stop digging yourself
> in deeper.
>
> Regards,
>
> Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
Stop that. I did not attack anyone.
On Wed, Feb 8, 2017 at 4:30 PM, Kevin A. McGrail <'KMcGrail@PCCC.com'> wrote:
On 2/8/2017 9:04 AM, Ruga wrote:
> Read the headers of RFCs; some o them are explicitly labeled as
> standard. Most of them are request for comments.
I'm well aware of the standards and don't appreciate being told to read
them. That's a personal attack and you are also attacking others who
are some of the best email people I've ever met.
Standards evolve organically and there is just "how it's done" as well
as the RFCs.
If these people are telling you it's "standard", don't start arguing the
definition of "standard". Take it on face value that you should do it
or risk losing important email.
To attack them and say they are forcing you to accept spam is nothing
but an argument fallacy because everyone is here to stop bastard spammers.
Regards,
KAM
Aiieee, stop it! (was Re: RFC compliance pedantry (was Re: New
type of monstrosity))
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Thu, 09 Feb 2017 08:21:28 -0500
Ruga <ru...@protonmail.com> wrote:
[nonsense]
I thought I'd take this opportunity to remind everyone of my Perl package
http://search.cpan.org/~dskoll/Mail-ThreadKiller-1.0.1/lib/Mail/ThreadKiller.pm
Regards,
Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
Speaking of personal attacks against me, how old are you?
On Thu, Feb 9, 2017 at 10:13 AM, Reindl Harald <'h.reindl@thelounge.net'> wrote:
Am 09.02.2017 um 09:28 schrieb Ruga:
>> A large class of wanted email comes with the "undisclosed recipients" header. A large class of wanted email comes from domains that lack SPF.
>
> Our security policy demands rejection of both types. They do not hit SA.
> They are denied as soon as their strings are received. The IP of
> repeated offenders is then dropped by firewall.
your childish posts are funny but slowly becoming annoying
you live in your own small world where you can do what you want if the
people which are owning the mailbox suck it - but don't pretend that
this works in the real world out there if you want to be taken serious
> On Thu, Feb 9, 2017 at 12:55 AM, Joe Quinn
> <'headprogrammingczar@gmail.com'> wrote:
>> On 2/8/2017 1:36 PM, Philip Prindeville wrote:
>>> Having been through the process of authoring 2 RFC’s, perhaps I can shed some light on the process for you.
>>>
>>> All proposed standards started life as draft RFC’s (this was before the days of IDEA’s but after the days of IEN’s).
>>>
>>> If it were validated by the working group and passed up to the IAB and they concurred (they usually deferred to the WG except on editorial matters), then the proposed draft was issued officially as an RFC and given a number.
>>>
>>> Later, after it accepted wide enough adoption in the Internet community, an existing RFC might be promoted to "standard" from "experimental", etc.
>>>
>>> Occasionally, if a WG (working group) did enough reference implementations and proved them at one or more interoperability meetings (the so-called "bake-offs"), then the WG could petition for immediate labeling as a "standard" when the RFC was approved by the IAB.
>>>
>>> It’s even possible for a standard (like RFC-1035) to have both "standard" parts (like A RR’s) and "experimental" parts (like MB RR’s).
>>>
>>>
>>>> On Feb 8, 2017, at 7:04 AM, Ruga <ru...@protonmail.com> wrote:
>>>>
>>>> Read the headers of RFCs; some o them are explicitly labeled as standard. Most of them are request for comments.
>>>>
>>>>
>>>> On Wed, Feb 8, 2017 at 2:58 PM, Kevin A. McGrail <'KMcGrail@PCCC.com'> wrote:
>>>>> On 2/8/2017 8:52 AM, Ruga wrote:
>>>>>> Not all RFCs are standards.
>>>>>> Educate yourself.
>>>>> The personal attacks aren't necessary. These RFCs are the basis for
>>>>> effectively 100% of the email on the planet for decades. If that's not
>>>>> a standard, what is?
>>
>> This bears some emphasis, actually. Going from experimental to
>> standard comes /after/ the implementations are used in practice and
>> proven to be useful. Beyond that, SA is not a standards checker or an
>> RFC checker or an IEEE checker. All it does is classify email as
>> wanted or not wanted. A large class of wanted email comes with the
>> "undisclosed recipients" header. A large class of wanted email comes
>> from domains that lack SPF. A smaller class of wanted email comes from
>> the actual manufacturer of Viagra. Some mail servers disregard some
>> standards entirely. You just have to deal with it.
>>
>> As Dianne points out, the "undisclosed recipients" to header is valid
>> under RFC822, which has been itself expanded on in multiple subsequent
>> RFCs. As multiple other people here have mentioned, the "undisclosed
>> recipients" to header is used in wanted email. I am right now two
>> clicks away from adding it to this email with my mail client. It is an
>> implementation detail of BCC, and unambiguously is not spam indicator
>> on its own.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
> A large class of wanted email comes with the "undisclosed recipients" header. A large class of wanted email comes from domains that lack SPF.
Our security policy demands rejection of both types. They do not hit SA. They are denied as soon as their strings are received. The IP of repeated offenders is then dropped by firewall.
On Thu, Feb 9, 2017 at 12:55 AM, Joe Quinn <'headprogrammingczar@gmail.com'> wrote:
On 2/8/2017 1:36 PM, Philip Prindeville wrote:
Having been through the process of authoring 2 RFC’s, perhaps I can shed some light on the process for you. All proposed standards started life as draft RFC’s (this was before the days of IDEA’s but after the days of IEN’s). If it were validated by the working group and passed up to the IAB and they concurred (they usually deferred to the WG except on editorial matters), then the proposed draft was issued officially as an RFC and given a number. Later, after it accepted wide enough adoption in the Internet community, an existing RFC might be promoted to "standard" from "experimental", etc. Occasionally, if a WG (working group) did enough reference implementations and proved them at one or more interoperability meetings (the so-called "bake-offs"), then the WG could petition for immediate labeling as a "standard" when the RFC was approved by the IAB. It’s even possible for a standard (like RFC-1035) to have both "standard" parts (like A RR’s) and "experimental" parts (like MB RR’s). On Feb 8, 2017, at 7:04 AM, Ruga [<ru...@protonmail.com>](mailto:ruga@protonmail.com) wrote: Read the headers of RFCs; some o them are explicitly labeled as standard. Most of them are request for comments. On Wed, Feb 8, 2017 at 2:58 PM, Kevin A. McGrail [<'KMcGrail@PCCC.com'>](mailto:'KMcGrail@PCCC.com') wrote: On 2/8/2017 8:52 AM, Ruga wrote: Not all RFCs are standards. Educate yourself. The personal attacks aren't necessary. These RFCs are the basis for effectively 100% of the email on the planet for decades. If that's not a standard, what is?
This bears some emphasis, actually. Going from experimental to standard comes after the implementations are used in practice and proven to be useful. Beyond that, SA is not a standards checker or an RFC checker or an IEEE checker. All it does is classify email as wanted or not wanted. A large class of wanted email comes with the "undisclosed recipients" header. A large class of wanted email comes from domains that lack SPF. A smaller class of wanted email comes from the actual manufacturer of Viagra. Some mail servers disregard some standards entirely. You just have to deal with it.
As Dianne points out, the "undisclosed recipients" to header is valid under RFC822, which has been itself expanded on in multiple subsequent RFCs. As multiple other people here have mentioned, the "undisclosed recipients" to header is used in wanted email. I am right now two clicks away from adding it to this email with my mail client. It is an implementation detail of BCC, and unambiguously is not spam indicator on its own.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 2/8/2017 9:04 AM, Ruga wrote:
> Read the headers of RFCs; some o them are explicitly labeled as
> standard. Most of them are request for comments.
I'm well aware of the standards and don't appreciate being told to read
them. That's a personal attack and you are also attacking others who
are some of the best email people I've ever met.
Standards evolve organically and there is just "how it's done" as well
as the RFCs.
If these people are telling you it's "standard", don't start arguing the
definition of "standard". Take it on face value that you should do it
or risk losing important email.
To attack them and say they are forcing you to accept spam is nothing
but an argument fallacy because everyone is here to stop bastard spammers.
Regards,
KAM
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Joe Quinn <he...@gmail.com>.
On 2/8/2017 1:36 PM, Philip Prindeville wrote:
> Having been through the process of authoring 2 RFC\u2019s, perhaps I can shed some light on the process for you.
>
> All proposed standards started life as draft RFC\u2019s (this was before the days of IDEA\u2019s but after the days of IEN\u2019s).
>
> If it were validated by the working group and passed up to the IAB and they concurred (they usually deferred to the WG except on editorial matters), then the proposed draft was issued officially as an RFC and given a number.
>
> Later, after it accepted wide enough adoption in the Internet community, an existing RFC might be promoted to \u201cstandard\u201d from \u201cexperimental\u201d, etc.
>
> Occasionally, if a WG (working group) did enough reference implementations and proved them at one or more interoperability meetings (the so-called \u201cbake-offs\u201d), then the WG could petition for immediate labeling as a \u201cstandard\u201d when the RFC was approved by the IAB.
>
> It\u2019s even possible for a standard (like RFC-1035) to have both \u201cstandard\u201d parts (like A RR\u2019s) and \u201cexperimental\u201d parts (like MB RR\u2019s).
>
>
>> On Feb 8, 2017, at 7:04 AM, Ruga <ru...@protonmail.com> wrote:
>>
>> Read the headers of RFCs; some o them are explicitly labeled as standard. Most of them are request for comments.
>>
>>
>> On Wed, Feb 8, 2017 at 2:58 PM, Kevin A. McGrail <'KMcGrail@PCCC.com'> wrote:
>>> On 2/8/2017 8:52 AM, Ruga wrote:
>>>> Not all RFCs are standards.
>>>> Educate yourself.
>>> The personal attacks aren't necessary. These RFCs are the basis for
>>> effectively 100% of the email on the planet for decades. If that's not
>>> a standard, what is?
This bears some emphasis, actually. Going from experimental to standard
comes /after/ the implementations are used in practice and proven to be
useful. Beyond that, SA is not a standards checker or an RFC checker or
an IEEE checker. All it does is classify email as wanted or not wanted.
A large class of wanted email comes with the "undisclosed recipients"
header. A large class of wanted email comes from domains that lack SPF.
A smaller class of wanted email comes from the actual manufacturer of
Viagra. Some mail servers disregard some standards entirely. You just
have to deal with it.
As Dianne points out, the "undisclosed recipients" to header is valid
under RFC822, which has been itself expanded on in multiple subsequent
RFCs. As multiple other people here have mentioned, the "undisclosed
recipients" to header is used in wanted email. I am right now two clicks
away from adding it to this email with my mail client. It is an
implementation detail of BCC, and unambiguously is not spam indicator on
its own.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
Having been through the process of authoring 2 RFC’s, perhaps I can shed some light on the process for you.
All proposed standards started life as draft RFC’s (this was before the days of IDEA’s but after the days of IEN’s).
If it were validated by the working group and passed up to the IAB and they concurred (they usually deferred to the WG except on editorial matters), then the proposed draft was issued officially as an RFC and given a number.
Later, after it accepted wide enough adoption in the Internet community, an existing RFC might be promoted to “standard” from “experimental”, etc.
Occasionally, if a WG (working group) did enough reference implementations and proved them at one or more interoperability meetings (the so-called “bake-offs”), then the WG could petition for immediate labeling as a “standard” when the RFC was approved by the IAB.
It’s even possible for a standard (like RFC-1035) to have both “standard” parts (like A RR’s) and “experimental” parts (like MB RR’s).
> On Feb 8, 2017, at 7:04 AM, Ruga <ru...@protonmail.com> wrote:
>
> Read the headers of RFCs; some o them are explicitly labeled as standard. Most of them are request for comments.
>
>
> On Wed, Feb 8, 2017 at 2:58 PM, Kevin A. McGrail <'KMcGrail@PCCC.com'> wrote:
>> On 2/8/2017 8:52 AM, Ruga wrote:
>> > Not all RFCs are standards.
>> > Educate yourself.
>> The personal attacks aren't necessary. These RFCs are the basis for
>> effectively 100% of the email on the planet for decades. If that's not
>> a standard, what is?
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
Read the headers of RFCs; some o them are explicitly labeled as standard. Most of them are request for comments.
On Wed, Feb 8, 2017 at 2:58 PM, Kevin A. McGrail <'KMcGrail@PCCC.com'> wrote:
On 2/8/2017 8:52 AM, Ruga wrote:
> Not all RFCs are standards.
> Educate yourself.
The personal attacks aren't necessary. These RFCs are the basis for
effectively 100% of the email on the planet for decades. If that's not
a standard, what is?
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 2/8/2017 8:52 AM, Ruga wrote:
> Not all RFCs are standards.
> Educate yourself.
The personal attacks aren't necessary. These RFCs are the basis for
effectively 100% of the email on the planet for decades. If that's not
a standard, what is?
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
Not all RFCs are standards.
Educate yourself.
Sent from ProtonMail Mobile
On Wed, Feb 8, 2017 at 1:38 PM, Matus UHLAR - fantomas <'uhlar@fantomas.sk'> wrote:
On 07.02.17 18:33, Ruga wrote:
>I follow the actual RFC standard, not the proposed revisions.
what are you talking about?
822, 2822 and 5322 all define group address form as allowed.
> If the sender hides the recipients, why should I care delivering its junk
> to my valued accounts?
you can create a rule for yourself that will score those headers.
However others will probably not use it, since it's quite common for some
companies to send mass mail to addresses not known to recipients
(so they won't abuse those addresses).
>Bear in mind the state of corruption we live in. Spam is also a business,
> and the RFC proposed revisions are adapting to such business, to allow for
> it instead of impeding it.
so why don't you follow those proposed revisions as you have stated above?
>On the subject length, although the RFC standard did not foresee the abuse,
> it did speak about the intended purpose of the field. If it does not fit
> the one line of 78 (ASCII) characters, it bounches back to the sender. I
> understand that sloppy e-mail software allows spammers to send the library
> of congress inside a subject field, but rest assured that I such abuses do
> not survive my filters, even if Trump himself will allow for it with a
> presidential decree.
...and now you even want to ignore them at all...
simply try defining rules for long subjects and score them properly.
This should be just enough:
header SUBJECT_OVER_78 Subject =~ /^.{79}/
header SUBJECT_OVER_100 Subject =~ /^.{101}/
--
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.
"Where do you want to go to die?" [Microsoft]
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 07.02.17 18:33, Ruga wrote:
>I follow the actual RFC standard, not the proposed revisions.
what are you talking about?
822, 2822 and 5322 all define group address form as allowed.
> If the sender hides the recipients, why should I care delivering its junk
> to my valued accounts?
you can create a rule for yourself that will score those headers.
However others will probably not use it, since it's quite common for some
companies to send mass mail to addresses not known to recipients
(so they won't abuse those addresses).
>Bear in mind the state of corruption we live in. Spam is also a business,
> and the RFC proposed revisions are adapting to such business, to allow for
> it instead of impeding it.
so why don't you follow those proposed revisions as you have stated above?
>On the subject length, although the RFC standard did not foresee the abuse,
> it did speak about the intended purpose of the field. If it does not fit
> the one line of 78 (ASCII) characters, it bounches back to the sender. I
> understand that sloppy e-mail software allows spammers to send the library
> of congress inside a subject field, but rest assured that I such abuses do
> not survive my filters, even if Trump himself will allow for it with a
> presidential decree.
...and now you even want to ignore them at all...
simply try defining rules for long subjects and score them properly.
This should be just enough:
header SUBJECT_OVER_78 Subject =~ /^.{79}/
header SUBJECT_OVER_100 Subject =~ /^.{101}/
--
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.
"Where do you want to go to die?" [Microsoft]
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
A mailing list does not need to hide the recipients.
This mailing list, for example, uses a good policy.
-------- Original Message --------
Subject: Re: RFC compliance pedantry (was Re: New type of monstrosity)
Local Time: 8 February 2017 3:04 AM
UTC Time: 8 February 2017 02:04
From: itz@primate.net
To: users@spamassassin.apache.org
On 2017-02-07 18:33, Ruga wrote:
> I follow the actual RFC standard, not the proposed revisions. The To
> From and Cc fields are defined by a grammar AND a natural language
> description. Such fields MUST hold addresses, were an address is a
> username the "@" symbol and a domain name. The string "undisclosed
> recipients: ;" does not parse the grammar, and it does not pass the
> natural language requirement for an address. If the sender hides the
> recipients, why should I care delivering its junk to my valued
> accounts?
FWIW, I regularly get completely legitimate non-commercial messages with
headers of this form. People use it to conceal from each recipient the
addresses of other recipients - just like a list or an alias, but (I'm
guessing) done entirely in the senders MUA.
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
> So, Ruga, if you just want to BCC a bunch of people, what do you propose
> [we] should be put into the To: header?
I would use this or similar:
To: no-reply@your.domain.com
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by John Hardin <jh...@impsec.org>.
On Tue, 7 Feb 2017, Ian Zimmerman wrote:
> On 2017-02-07 18:33, Ruga wrote:
>
>> I follow the actual RFC standard, not the proposed revisions. The To
>> From and Cc fields are defined by a grammar AND a natural language
>> description. Such fields MUST hold addresses, were an address is a
>> username the "@" symbol and a domain name. The string "undisclosed
>> recipients: ;" does not parse the grammar, and it does not pass the
>> natural language requirement for an address. If the sender hides the
>> recipients, why should I care delivering its junk to my valued
>> accounts?
>
> FWIW, I regularly get completely legitimate non-commercial messages with
> headers of this form. People use it to conceal from each recipient the
> addresses of other recipients - just like a list or an alias, but (I'm
> guessing) done entirely in the senders MUA.
Right.
So, Ruga, if you just want to BCC a bunch of people, what do you propose
should be put into the To: header?
--
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
-----------------------------------------------------------------------
When designing software, any time you think to yourself "a user
would never be stupid enough to do *that*", you're wrong.
-----------------------------------------------------------------------
5 days until Abraham Lincoln's and Charles Darwin's 208th Birthdays
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ian Zimmerman <it...@primate.net>.
On 2017-02-07 18:33, Ruga wrote:
> I follow the actual RFC standard, not the proposed revisions. The To
> From and Cc fields are defined by a grammar AND a natural language
> description. Such fields MUST hold addresses, were an address is a
> username the "@" symbol and a domain name. The string "undisclosed
> recipients: ;" does not parse the grammar, and it does not pass the
> natural language requirement for an address. If the sender hides the
> recipients, why should I care delivering its junk to my valued
> accounts?
FWIW, I regularly get completely legitimate non-commercial messages with
headers of this form. People use it to conceal from each recipient the
addresses of other recipients - just like a list or an alias, but (I'm
guessing) done entirely in the senders MUA.
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
RFC-822 is the e-mail standard, without "group addresses". What we do complies with the standard.
Sent from ProtonMail Mobile
On Thu, Feb 9, 2017 at 2:19 PM, Dianne Skoll <'dfs@roaringpenguin.com'> wrote:
On Thu, 09 Feb 2017 03:44:24 -0500
Ruga <ru...@protonmail.com> wrote:
> Proper snail mail and e-mail have addresses. Those who do not, are
> quickly archived in the trashcan. This is what we do, and it works.
We get it.
I'm overcome with delight that you are implementing the mail policy
that you like. It warms my heart... you have no idea.
But please don't claim you're doing it in the name of RFC compliance.
Regards,
Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Thu, 09 Feb 2017 03:44:24 -0500
Ruga <ru...@protonmail.com> wrote:
> Proper snail mail and e-mail have addresses. Those who do not, are
> quickly archived in the trashcan. This is what we do, and it works.
We get it.
I'm overcome with delight that you are implementing the mail policy
that you like. It warms my heart... you have no idea.
But please don't claim you're doing it in the name of RFC compliance.
Regards,
Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
Proper snail mail and e-mail have addresses. Those who do not, are quickly archived in the trashcan. This is what we do, and it works.
On Wed, Feb 8, 2017 at 3:13 PM, David Jones <'djones@ena.com'> wrote:
>From: Ruga <ru...@protonmail.com>
>Sent: Wednesday, February 8, 2017 8:01 AM
>How odd, in a mailing list of spam fighters someone really
>wants me to accept junk mail.
>In the snail mail box, we put in the trashcan everything that
>does not carry a recipient address. Guess what? We do the
>same with e-mail. And we are happy about it.
Snail mail doesn't support the concept of BCC and email
does. BCC'ing is legit and it's tough to block spam that is
sent this way but it's doable, just not based on the To:
header.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by David Jones <dj...@ena.com>.
>From: Ruga <ru...@protonmail.com>
>Sent: Wednesday, February 8, 2017 8:01 AM
>How odd, in a mailing list of spam fighters someone really
>wants me to accept junk mail.
>In the snail mail box, we put in the trashcan everything that
>does not carry a recipient address. Guess what? We do the
>same with e-mail. And we are happy about it.
Snail mail doesn't support the concept of BCC and email
does. BCC'ing is legit and it's tough to block spam that is
sent this way but it's doable, just not based on the To:
header.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
Remind me to tell you when I use the iPhone.
On Thu, Feb 9, 2017 at 1:13 PM, Dianne Skoll <'dfs@roaringpenguin.com'> wrote:
On February 9, 2017 3:41:32 AM EST, Ruga <ru...@protonmail.com> wrote:
>Let see who can read amon us.
You spelled "among" incorrectly.
>What is your highest level of formal education?
Um? None of your business?
Master's degree, if you must know.
-- Dianne
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On February 9, 2017 3:41:32 AM EST, Ruga <ru...@protonmail.com> wrote:
>Let see who can read amon us.
You spelled "among" incorrectly.
>What is your highest level of formal education?
Um? None of your business?
Master's degree, if you must know.
-- Dianne
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
> You really don't know how to read, do you?
Now this is a personal attack from you.
Let see who can read amon us.
What is your highest level of formal education?
On Wed, Feb 8, 2017 at 3:24 PM, Dianne Skoll <'dfs@roaringpenguin.com'> wrote:
On Wed, 08 Feb 2017 09:01:35 -0500
Ruga <ru...@protonmail.com> wrote:
> How odd, in a mailing list of spam fighters someone really wants me
> to accept junk mail.
Wow. You really don't know how to read, do you? What was unclear
about my statement:
Hey, you do you. You can do whatever you want with your mail, but
claiming it's in the name of RFC compliance is alternatively factual.
> In the snail mail box, we put in the trashcan everything that does
> not carry a recipient address. Guess what? We do the same with
> e-mail. And we are happy about it.
You can do whatever you want. But don't spread misinformation about
standards. We have to deal with enough crappy noncompliant software.
We don't need Internet vigilantes on a witch-hunt against software
that actually *does* comply with standards.
Regards,
Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Wed, 08 Feb 2017 09:01:35 -0500
Ruga <ru...@protonmail.com> wrote:
> How odd, in a mailing list of spam fighters someone really wants me
> to accept junk mail.
Wow. You really don't know how to read, do you? What was unclear
about my statement:
Hey, you do you. You can do whatever you want with your mail, but
claiming it's in the name of RFC compliance is alternatively factual.
> In the snail mail box, we put in the trashcan everything that does
> not carry a recipient address. Guess what? We do the same with
> e-mail. And we are happy about it.
You can do whatever you want. But don't spread misinformation about
standards. We have to deal with enough crappy noncompliant software.
We don't need Internet vigilantes on a witch-hunt against software
that actually *does* comply with standards.
Regards,
Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
How odd, in a mailing list of spam fighters someone really wants me to accept junk mail.
In the snail mail box, we put in the trashcan everything that does not carry a recipient address. Guess what? We do the same with e-mail. And we are happy about it.
On Wed, Feb 8, 2017 at 2:43 PM, Dianne Skoll <'dfs@roaringpenguin.com'> wrote:
On Tue, 07 Feb 2017 18:33:49 -0500
Ruga <ru...@protonmail.com> wrote:
> I follow the actual RFC standard, not the proposed revisions.
No you don't. You follow your misunderstanding of the actual standard.
RFC822 permits group syntax. It's right in the ABNF. Learn to read
carefully.
Here's a hint, taken directly from https://www.ietf.org/rfc/rfc0822.txt
address = mailbox ; one addressee
/ group ; named list
group = phrase ":" [#mailbox] ";"
> The To From and Cc fields are defined by a grammar AND a natural
> language description. Such fields MUST hold addresses,
Wrong.
> Bear in mind the state of corruption we live in.
I know. It's awful that would-be pedants don't even read properly.
> On the subject length, although the RFC standard did not foresee the
> abuse, it did speak about the intended purpose of the field. If it
> does not fit the one line of 78 (ASCII) characters, it bounches back
> to the sender.
Well, you know, for someone who only follows STANDARDS, you're making stuff
up. There's no mention whatsoever of line length limits in the STANDARD
RFC 822. Those are only in the proposed revisions, which you disdain.
Or are you selective about picking and choosing from proposed revisions?
Oh and by the way, I certainly hope your mail server does not speak
ESMTP. That's not a standard, you know.
> I understand that sloppy e-mail software allows
> spammers to send the library of congress inside a subject field, but
> rest assured that I such abuses do not survive my filters, even if
> Trump himself will allow for it with a presidential decree.
Hey, you do you. You can do whatever you want with your mail, but claiming
it's in the name of RFC compliance is alternatively factual.
Regards,
Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Tue, 07 Feb 2017 18:33:49 -0500
Ruga <ru...@protonmail.com> wrote:
> I follow the actual RFC standard, not the proposed revisions.
No you don't. You follow your misunderstanding of the actual standard.
RFC822 permits group syntax. It's right in the ABNF. Learn to read
carefully.
Here's a hint, taken directly from https://www.ietf.org/rfc/rfc0822.txt
address = mailbox ; one addressee
/ group ; named list
group = phrase ":" [#mailbox] ";"
> The To From and Cc fields are defined by a grammar AND a natural
> language description. Such fields MUST hold addresses,
Wrong.
> Bear in mind the state of corruption we live in.
I know. It's awful that would-be pedants don't even read properly.
> On the subject length, although the RFC standard did not foresee the
> abuse, it did speak about the intended purpose of the field. If it
> does not fit the one line of 78 (ASCII) characters, it bounches back
> to the sender.
Well, you know, for someone who only follows STANDARDS, you're making stuff
up. There's no mention whatsoever of line length limits in the STANDARD
RFC 822. Those are only in the proposed revisions, which you disdain.
Or are you selective about picking and choosing from proposed revisions?
Oh and by the way, I certainly hope your mail server does not speak
ESMTP. That's not a standard, you know.
> I understand that sloppy e-mail software allows
> spammers to send the library of congress inside a subject field, but
> rest assured that I such abuses do not survive my filters, even if
> Trump himself will allow for it with a presidential decree.
Hey, you do you. You can do whatever you want with your mail, but claiming
it's in the name of RFC compliance is alternatively factual.
Regards,
Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Wed, 08 Feb 2017 07:16:48 -0500
Ruga <ru...@protonmail.com> wrote:
> It is precisely because I am responsible for other persons that I
> make such rules based upon the RFC standard,
No, you don't. You make the rules based on your misreading of RFC 822.
RFC 822 permits this header:
To: undisclosed recipients:;
End of story.
Regards,
Dianne.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
> you can do that for your *personal* mailserver but most admins on that
> planet are also repsonsible for other peoles mailbox and you can't apply
> such interpretation of rules their because your primary job is *to
> receive and deliver emails* and not to reject them and educate the world
> if i could i would enable a lof of filters which in combination would
> eliminate the remaining 1% of junk but as long as people have more
> damage with 1 false positive than 10 slipped junk mails it's just not possible
It is precisely because I am responsible for other persons that I make such rules
based upon the RFC standard, with bounce messages to educate the senders.
Domains that send e-mail to us are domains that we care for.
Take gmail, for example. They improve their policies, and everybody goes along with it.
Last month, they decided to reject JavaScript attachments upfront. There is no RFC
that says "you MUST reject JavaScript attachments", and yet, they do it, and for a very good reason.
Re: RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Ruga <ru...@protonmail.com>.
I follow the actual RFC standard, not the proposed revisions. The To From and Cc fields are defined by a grammar AND a natural language description. Such fields MUST hold addresses, were an address is a username the "@" symbol and a domain name. The string "undisclosed recipients: ;" does not parse the grammar, and it does not pass the natural language requirement for an address. If the sender hides the recipients, why should I care delivering its junk to my valued accounts?
Bear in mind the state of corruption we live in. Spam is also a business, and the RFC proposed revisions are adapting to such business, to allow for it instead of impeding it.
On the subject length, although the RFC standard did not foresee the abuse, it did speak about the intended purpose of the field. If it does not fit the one line of 78 (ASCII) characters, it bounches back to the sender. I understand that sloppy e-mail software allows spammers to send the library of congress inside a subject field, but rest assured that I such abuses do not survive my filters, even if Trump himself will allow for it with a presidential decree.
On Tue, Feb 7, 2017 at 5:28 PM, Dianne Skoll <'dfs@roaringpenguin.com'> wrote:
On Tue, 07 Feb 2017 02:57:06 -0500
Ruga <ru...@protonmail.com> wrote:
> > To: undisclosed recipients: ;
> The To header is not RFC compliant.
Yes it is. RFC 5322 even gives the header Cc: undisclosed recipients: ;
as an example in Appendix A.1.3, Group Addresses.
> The Subject header exceeds the
> maximum line length, being another RFC constraints.
Nope. It's around 720 characters, less than the 998 maximum. And
while it's true that it's not wrapped at 78 characters, that's a SHOULD
requirement, not a MUST requirement.
Anyway, we see a few of these every so often. Bayes usually disposes
of them quite handily.
Regards,
Dianne.
RFC compliance pedantry (was Re: New type of monstrosity)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Tue, 07 Feb 2017 02:57:06 -0500
Ruga <ru...@protonmail.com> wrote:
> > To: undisclosed recipients: ;
> The To header is not RFC compliant.
Yes it is. RFC 5322 even gives the header Cc: undisclosed recipients: ;
as an example in Appendix A.1.3, Group Addresses.
> The Subject header exceeds the
> maximum line length, being another RFC constraints.
Nope. It's around 720 characters, less than the 998 maximum. And
while it's true that it's not wrapped at 78 characters, that's a SHOULD
requirement, not a MUST requirement.
Anyway, we see a few of these every so often. Bayes usually disposes
of them quite handily.
Regards,
Dianne.
Re: New type of monstrosity
Posted by Dianne Skoll <df...@roaringpenguin.com>.
Ruga <ru...@protonmail.com> wrote:
> RFC-822 is the e-mail standard, without "group addresses". What we do
> complies with the standard.
You are wrong. Wrong, wrong, wrong, wrong.
Take a look at RFC-822: https://www.ietf.org/rfc/rfc0822.txt
Go to Section 6. ADDRESS SPECIFICATION. Look at Section 6.1.
Here's a copy/paste:
address = mailbox ; one addressee
/ group ; named list
group = phrase ":" [#mailbox] ";"
Oh look! The group address specification! In RFC 822! Amazing!
Ruga, my dear fellow, (or lady... I can't tell), stop digging yourself
in deeper.
Regards,
Dianne.
Re: New type of monstrosity
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 2/7/2017 2:57 AM, Ruga wrote:
> The spample would never make it to our SA. It would be rejected
> upstream for at least two reasons:
That was my thought as well. I've never seen this type of spam and that
was my expectation as well.
Re: New type of monstrosity
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 07.02.17 02:57, Ruga wrote:
>The spample would never make it to our SA. It would be rejected upstream for at least two reasons:
>
>> To: undisclosed recipients: ;
>
>
>The To header is not RFC compliant.
but very common...
>The Subject header exceeds the maximum line length, being another RFC constraints. It is easy to catch spam this way.
yes, we just need to find the length(s)...
--
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.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]
Re: New type of monstrosity
Posted by Ruga <ru...@protonmail.com>.
The spample would never make it to our SA. It would be rejected upstream for at least two reasons:
> To: undisclosed recipients: ;
The To header is not RFC compliant.The Subject header exceeds the maximum line length, being another RFC constraints. It is easy to catch spam this way.
On Tue, Feb 7, 2017 at 3:46 AM, Ian Zimmerman <'itz@primate.net'> wrote:
On 2017-02-06 20:06, Kevin A. McGrail wrote:
> > Last couple of weeks I saw some messages whose entire contents is in
> > the Subject.
> never seen such a monster. likely killed by some other piece in the
> puzzle. Throw it up on pastebin?
http://pastebin.com/PYaMcZa7
(I was wrong, the subject is actually one enormous line, it was my MUA
that folded it.)
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: New type of monstrosity
Posted by RW <rw...@googlemail.com>.
On Mon, 6 Feb 2017 18:46:47 -0800
Ian Zimmerman wrote:
> On 2017-02-06 20:06, Kevin A. McGrail wrote:
>
> > > Last couple of weeks I saw some messages whose entire contents is
> > > in the Subject.
>
> > never seen such a monster. likely killed by some other piece in the
> > puzzle. Throw it up on pastebin?
>
> http://pastebin.com/PYaMcZa7
From: "Barrister Felix D. Acheampong" <fl...@outlook.fr>
If anyone's interested:
header FROM_TITLE_BOGUS from:name =~ /^\W*(?:bar+(?:ister)?|lawyer)\b/i
describe FROM_TITLE_BOGUS From name starts with a bogus title
score FROM_TITLE_BOGUS 3.5
I don't get many hits on it these days, but it is very cheap.
Re: New type of monstrosity
Posted by Ian Zimmerman <it...@primate.net>.
On 2017-02-07 09:37, Matus UHLAR - fantomas wrote:
> 11.5 - 3.5 = 8.0
And of course 1.2.3.x is not the true relay address, so
> 1.5 BOTNET Relay might be a spambot or virusbot
> [botnet0.8,ip=1.2.3.12,rdns=disorder.censored.net,maildomain=outlook.fr,baddns]
this goes out of the window as well, and you're down to 6.5
> the op may be early recipient, which is why you've got PYZOR hit,
> while the OP had not. If the OP doesnt't use pyzor, I recomment to
> use it - using razor, pyzor and DCC is very good idea although they
> need external software.
I used to have pyzor, but I dropped it for some reason I don't
remember. It may be time to have another look at it.
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: New type of monstrosity
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>Ian Zimmerman kirjoitti 7.2.2017 4:46:
>> On 2017-02-06 20:06, Kevin A. McGrail wrote:
>>
>>> > Last couple of weeks I saw some messages whose entire contents is in
>>> > the Subject.
>>
>>> never seen such a monster. likely killed by some other piece in the
>>> puzzle. Throw it up on pastebin?
>>
>> http://pastebin.com/PYaMcZa7
>>
>> (I was wrong, the subject is actually one enormous line, it was my MUA
>> that folded it.)
On 07.02.17 09:05, Jari Fredriksson wrote:
>Content analysis details: (11.5 points, 5.0 required)
>
> pts rule name description
>- ---- ----------------------
>- --------------------------------------------------
> 1.0 GENERIC_IXHASH No description available.
3rd party plugin
> 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source
> [183.79.56.200 listed in dnsbl.sorbs.net]
> 1.5 BOTNET Relay might be a spambot or virusbot
>[botnet0.8,ip=1.2.3.12,rdns=disorder.censored.net,maildomain=outlook.fr,baddns]
3rd party plugin (iirc reported to cause issues at providers with dynamic IPs)
> 0.0 SPF_HELO_FAIL SPF: HELO does not match SPF record (fail)
>[SPF failed: Please see
>http://www.openspf.org/Why?s=helo;id=acedia.censored.net;ip=1.2.3.12;r=gamecock.fredriksson.dy.fi]
> 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record
>(softfail)
> 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
>provider
> (flexdanacheam[at]outlook.fr)
> 1.0 HTML_MESSAGE BODY: HTML included in message
> 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
> [score: 0.5061]
> 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not
>necessarily valid
> 1.4 PYZOR_CHECK Listed in Pyzor (http://pyzor.sf.net/)
> 1.0 L_FROM_NOT_REPLY From: and Reply-To: have different domains
local rule.
> 0.0 LOTS_OF_MONEY Huge... sums of money
> 0.0 MONEY_BARRISTER Lots of money from a UK lawyer
> 1.0 FREEMAIL_REPLYTO Reply-To/From or Reply-To/body contain
>different
> freemails
> 0.0 FILL_THIS_FORM Fill in a form with personal information
> 0.0 T_FILL_THIS_FORM_LONG Fill in a form with personal information
> 2.5 SPOOFED_FREEM_REPTO Forged freemail sender with freemail
>reply-to
> 0.0 ADVANCE_FEE_5_NEW_FRM_MNY Advance Fee fraud form and lots of money
> 0.0 MONEY_FRAUD_5 Lots of money and many fraud phrases
11.5 - 3.5 = 8.0
also, the OP got RCVD_IN_MSPIKE_H2 (-1.9), which was apparently removed since.
the op may be early recipient, which is why you've got PYZOR hit, while the
OP had not. If the OP doesnt't use pyzor, I recomment to use it - using
razor, pyzor and DCC is very good idea although they need external software.
--
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.
Linux is like a teepee: no Windows, no Gates and an apache inside...
Re: New type of monstrosity
Posted by Jari Fredriksson <ja...@iki.fi>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ian Zimmerman kirjoitti 7.2.2017 4:46:
> On 2017-02-06 20:06, Kevin A. McGrail wrote:
>
>> > Last couple of weeks I saw some messages whose entire contents is in
>> > the Subject.
>
>> never seen such a monster. likely killed by some other piece in the
>> puzzle. Throw it up on pastebin?
>
> http://pastebin.com/PYaMcZa7
>
> (I was wrong, the subject is actually one enormous line, it was my MUA
> that folded it.)
Content analysis details: (11.5 points, 5.0 required)
pts rule name description
- ---- ----------------------
- --------------------------------------------------
1.0 GENERIC_IXHASH No description available.
0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source
[183.79.56.200 listed in dnsbl.sorbs.net]
1.5 BOTNET Relay might be a spambot or virusbot
[botnet0.8,ip=1.2.3.12,rdns=disorder.censored.net,maildomain=outlook.fr,baddns]
0.0 SPF_HELO_FAIL SPF: HELO does not match SPF record (fail)
[SPF failed: Please see
http://www.openspf.org/Why?s=helo;id=acedia.censored.net;ip=1.2.3.12;r=gamecock.fredriksson.dy.fi]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record
(softfail)
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider
(flexdanacheam[at]outlook.fr)
1.0 HTML_MESSAGE BODY: HTML included in message
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5061]
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not
necessarily valid
1.4 PYZOR_CHECK Listed in Pyzor (http://pyzor.sf.net/)
1.0 L_FROM_NOT_REPLY From: and Reply-To: have different domains
0.0 LOTS_OF_MONEY Huge... sums of money
0.0 MONEY_BARRISTER Lots of money from a UK lawyer
1.0 FREEMAIL_REPLYTO Reply-To/From or Reply-To/body contain
different
freemails
0.0 FILL_THIS_FORM Fill in a form with personal information
0.0 T_FILL_THIS_FORM_LONG Fill in a form with personal information
2.5 SPOOFED_FREEM_REPTO Forged freemail sender with freemail
reply-to
0.0 ADVANCE_FEE_5_NEW_FRM_MNY Advance Fee fraud form and lots of money
0.0 MONEY_FRAUD_5 Lots of money and many fraud phrases
- --
jarif@iki.fi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAliZcbkACgkQKL4IzOyjSrZxcACdFN8ZdEkcZWwO6n44neBGjHCX
Vi0Anjai2SZRaJ2bi8PsSFJ08yP3JtnP
=LDLO
-----END PGP SIGNATURE-----
Re: New type of monstrosity
Posted by Ian Zimmerman <it...@primate.net>.
On 2017-02-06 20:06, Kevin A. McGrail wrote:
> > Last couple of weeks I saw some messages whose entire contents is in
> > the Subject.
> never seen such a monster. likely killed by some other piece in the
> puzzle. Throw it up on pastebin?
http://pastebin.com/PYaMcZa7
(I was wrong, the subject is actually one enormous line, it was my MUA
that folded it.)
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: New type of monstrosity
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 2/6/2017 7:52 PM, Ian Zimmerman wrote:
> Last couple of weeks I saw some messages whose entire contents is in the
> Subject. They have both a text/plain and text/html part but both are
> empty (in the case of html, there is some markup but no character
> data). The Subject is maybe 400 or 500 chars long.
>
> Needless to say, this is a 100% spam trait, but some escaped.
>
> Is there already a rule somewhere to deal with this? (not among the
> ones bundled with SA, I don't think)
>
> If I'm writing my own, is the naive way to match the Subject going to
> work? I'm asking mostly because the header is properly split and
> continued around 60 character bonudaries. That is, does SA join
> continued lines before matching?
never seen such a monster. likely killed by some other piece in the
puzzle. Throw it up on pastebin?