Re: Direct download link detection

[Ian Zimmerman]

On 2017-07-27 13:08, Rupert Gallagher wrote:

> The rfc prescribes (MUST) the use of your public domain in the domain
> part of your mid.

If you mean RFC 5322, this is not true.  Section 3.6.4:

   The message identifier (msg-id) itself MUST be a globally unique
   identifier for a message.  The generator of the message identifier
   MUST guarantee that the msg-id is unique.  There are several
   algorithms that can be used to accomplish this.  Since the msg-id has
   a similar syntax to addr-spec (identical except that quoted strings,
   comments, and folding white space are not allowed), a good method is
   to put the domain name (or a domain literal IP address) of the host
   on which the message identifier was created on the right-hand side of
   the "@" (since domain names and IP addresses are normally unique),
   and put a combination of the current absolute date and time along
   with some other currently unique (perhaps sequential) identifier
   available on the system (for example, a process id number) on the
   left-hand side.  Though other algorithms will work, it is RECOMMENDED
   that the right-hand side contain some domain identifier (either of
   the host itself or otherwise) such that the generator of the message
   identifier can guarantee the uniqueness of the left-hand side within
   the scope of that domain.

Or do you mean some other RFC, which one?

> So the dns tests are just the first in the queue. The dimain must also
> match early in the Reveived list.

Huh?  Even corrected for the obvious typos, this doesn't make sense.
We're talking about the Message-ID here.

> If you fail with it, then you have problems with every rfc-compliant
> smtp server world-wide. This filter is especially useful against
> scripts, spamming programs, and web-based mailers.

You're free to lose any incoming mail you like, including mine :-)
Though apparently you do get my messages, so I am confused about what
your filter actually does.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: Direct download link detection

[Rupert Gallagher]

The rfc prescribes (MUST) the use of your public domain in the domain part of 
your mid. So the dns tests are just the first in the queue. The dimain must 
also match early in the Reveived list. If you fail with it, then you have 
problems with every rfc-compliant smtp server world-wide. This filter is 
especially useful against scripts, spamming programs, and web-based mailers.
Sent from ProtonMail Mobile

On Wed, Jul 26, 2017 at 6:07 PM, Ian Zimmerman  wrote:

> On 2017-07-26 02:48, Rupert Gallagher wrote: > When a mail arrives without 
> mid, either the sender did not use a real > SMTP server or tried to hide it. 
> We have a custom SA rule for it. We > also reject upfront any mid with a 
> syntax error, or whose domain does > not have a rdns (eg. 
> @localhost.localdomain or @test.com). I suspect you'll miss this message, 
> then. My Message-IDs intentionally identify the originating host, which makes 
> me more confident that they're unique. The originating host is behind two 
> layers of NAT and DHCP, and naturally doesn't have rDNS. I don't know how to 
> ensure uniqueness if I use the relaying SMTP server's domain, or the domain 
> of the perimeter of the NATted network, which can have rDNS (and does, via a 
> dyn-like update service), but which I do not own or control. -- Please don't 
> Cc: me privately on mailing lists and Usenet, if you also post the followup 
> to the list or newsgroup. Do obvious transformation on domain to reply 
> privately _only_ on Usenet.

Re: Direct download link detection

[Rupert Gallagher]

> Are you able to turn it off?
I tried. No such option. :-(
Sent from ProtonMail Mobile

On Wed, Jul 26, 2017 at 6:05 PM, Matus UHLAR - fantomas  
wrote:

> On 26.07.17 02:48, Rupert Gallagher wrote: >+1 to remove that clause from the 
> RFC. I don't see any reason... btw you'd need to change it to MUST NOT for 
> all to stop (which is unlikelly to happen). >When a mail arrives without mid, 
> either the sender did not use a real SMTP > server or tried to hide it. We 
> have a custom SA rule for it. We also > reject upfront any mid with a syntax 
> error, or whose domain does not have > a rdns (eg. @localhost.localdomain or 
> @test.com). nobody forbids you from doing this. SA has rules for both missing 
> and added Message-ID: header. you are welcome to reject based on anything... 
> >Sent from ProtonMail Mobile seems that protonmail mobile unwraps the lines, 
> which makes quoted text very hard to read. Are you able to turn it off? >On 
> Tue, Jul 25, 2017 at 5:20 PM, John Hardin wrote: > >> On Tue, 25 Jul 2017, 
> Rupert Gallagher wrote: > Before bothering with body spam, make sure the 
> header is clear. The > specific email should have been rejected upfront, 
> because the foreign > sender's message-id pretends to originate from the 
> recipient's smtp > server. That's potentially valid. If a MTA receives a 
> message that has no message ID it is valid to add one from the MTA's domain. 
> -- John Hardin KA7OHZ http://www.impsec.org/~jhardin/ jhar...@impsec.org 
> FALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 
> F507 136C AF76 D822 E6E6 B873 2E79 
> --- I 
> would buy a Mac today if I was not working at Microsoft. -- James Allchin, 
> Microsoft VP of Platforms 
> --- 10 
> days until the 282nd anniversary of John Peter Zenger's acquittal -- 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. Windows 2000: 640 MB ought to be 
> enough for anybody @impsec.org>

Re: Found clue for detecting lots of ".us" spam

[David Jones]

On 07/26/2017 10:39 PM, Rich Wales wrote:

I recently noticed a small detail which has allowed me to detect most of
the spam I've been receiving from random addresses ending in ".us".

On the one hand, I'd love to share my observation (and my custom rule
for detecting it), so others can benefit from my discovery.

On the other hand, I'm worried that the spammers (many of whom are no
doubt subscribed to this list) will take advantage of my generosity,
will change things so their stuff won't match my new rule, and will be
able to get through to me and other unwilling recipients again.

What is the consensus on this sort of thing?  Thanks for any feedback.

Rich Wales
ri...@richw.org



A few months ago I posted on this list that I had noticed some oddly 
named .us domains that match a very simple regex based on length of 
characters in the second and third levels.  You may want to post one of 
your your findings to pastebin without any specifics of your findings so 
the rest of us can look at it too.


--
Dave

Re: Mail::SpamAssassin::Plugin::EmailBL??

[hospice admin]

Thanks.



From: Kevin Golding 
Sent: 27 July 2017 14:41
To: users@spamassassin.apache.org
Subject: Re: Mail::SpamAssassin::Plugin::EmailBL??

On Thu, 27 Jul 2017 08:28:06 +0100, hospice admin 
wrote:

> the above plugin doesn't seem to be distributed with the version of
> SpamAssassin I'm running:
>
>
> spamassassin --version
> SpamAssassin version 3.4.0
>   running on Perl version 5.16.3
>
> Also, I can't find mention of a download location anywhere.
>
>
> Am I right in thinking this was an experiment that never quite made it
> out of the sand-box?

You are correct.

https://lists.gt.net/spamassassin/users/196582
Mailing List Archive: EmailBL.pm error, anyone 
knows?
lists.gt.net
Gossamer Mailing List Archive




I don't believe anyone has resurrected it since

Re: Mail::SpamAssassin::Plugin::EmailBL??

[Kevin Golding]

On Thu, 27 Jul 2017 08:28:06 +0100, hospice admin   
wrote:


the above plugin doesn't seem to be distributed with the version of  
SpamAssassin I'm running:



spamassassin --version
SpamAssassin version 3.4.0
  running on Perl version 5.16.3

Also, I can't find mention of a download location anywhere.


Am I right in thinking this was an experiment that never quite made it  
out of the sand-box?


You are correct.

https://lists.gt.net/spamassassin/users/196582

I don't believe anyone has resurrected it since

Mail::SpamAssassin::Plugin::EmailBL??

[hospice admin]

Hi,


the above plugin doesn't seem to be distributed with the version of 
SpamAssassin I'm running:


spamassassin --version
SpamAssassin version 3.4.0
  running on Perl version 5.16.3

Also, I can't find mention of a download location anywhere.


Am I right in thinking this was an experiment that never quite made it out of 
the sand-box?


Thanks


Judy