Re: RFC compliance pedantry (was Re: New type of monstrosity)
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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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)
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)
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 <'d...@roaringpenguin.com'> wrote: On Tue, 07 Feb 2017 02:57:06 -0500 Ruga 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
On Feb 7, 2017, at 12:57 AM, 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. Where do you get that idea? “Undisclosed recipient: ;” is a group address. RFS 2822 A.1.3: From: Pete To: A Group:Chris Jones ,j...@where.test,John ; Cc: Undisclosed recipients:; Date: Thu, 13 Feb 1969 23:32:54 -0330 Message-ID: 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.
RFC compliance pedantry (was Re: New type of monstrosity)
On Tue, 07 Feb 2017 02:57:06 -0500 Ruga 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
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
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" 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 scoreFROM_TITLE_BOGUS 3.5 I don't get many hits on it these days, but it is very cheap.
Re: New type of monstrosity
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
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
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, uh...@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
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_SIGNEDMessage has a DKIM or DK signature, not necessarily valid 1.4 PYZOR_CHECKListed 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_BARRISTERLots 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_REPTOForged 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, uh...@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...
