[colug-432] SPF and other stuff for personal domains

[Rick Troth]

On 02/13/2017 01:42 PM, Angelo McComis wrote:
> ?all means SPF neutral. It means the owner of the domain is not
> declaring what the recipient should do if the sending host is not
> listed. ​It's neither pass nor fail.  (so how is that even useful?)

I finally figgered out "?all" versus "~all". But ... yeah ... how is
"?all" even useful?


> a) First check:  IP check at the first connection, check against RBLs,
> and immediately just drop / disconnect known spammers, residential IP
> range, and so on.

Residential is not inherently spamish. But ... trying to boil just one
ocean at a time ...


> b) Next, check that the sender domain is valid for the IP it's coming
> from (SPF check).
> Start tallying score at this point.   Valid SPF, you give positive 50
> points.
> Neutral score, you give 0 points. Soft-fail, you give -10 points. 
> Hard-fail, you give -100 points.   
> Same with DKIM -- pass/fail ==> points added or subtracted from score.

I would think a valid DKIM signature would lead to hard /pass/.
(contrast with hard fail) What you describe could still be outweighed by
spammy content in later steps.   :-(

Philosophical, so I don't mean to be argumentative (and I appreciate
good info!), but the scoring game was a show stopper for me prior to
outsourcing. Makes perfect sense, but is a clear example of "profiling".

I do see that statistics/scoring will come around again. People are
starting to augment the traditional web-of-trust with multiple methods
of vetting. (proof of web site ownership, proof of Twitter handle, proof
of Github account, stuff like that) Accumulate four out of five "yeah,
that's really Angelo" for a given PGP key and maybe you can trust it.
Face-to-face vetting and manual assertion is cumbersome, not for
consumers or teenagers or grandma.


> c) You next check for valid recipient (this is easy to cache, so is
> not resource intensive) - Invalid recipient, bounce it back.
> d) You perform your chosen heuristics on the message (e.g. run it
> through Spam Assassin, OCR the images to check the text strings for
> spammy content, distributed checksum checker, etc.) and do more
> scoring (+ or -)
> e) Virus scan and phishing checks...
>
> If you've scored the message according to those rules, positive points
> gets passed to the inbox, up to -10 negative points gets flagged (like
> prepending the subject with [SPAM?] ) or something, and more than -10
> negative, and the message gets quarantined / dropped.
>
> With SPF Soft Fail, you can incorporate this into a scoring system
> with Spam Assassin, such that you can customize how much or how little
> a penalty to assign for soft-failing SPF, or DKIM.  If everything else
> passes, you might pass the message as OK. 

Excellent details.

So ... no known receivers use SPF as a "hard pass". (e.g., it came from
a sender in an IP4 block, so it's gotta be good)
Correct?


> The thing to remember as I've outlined in my example defense-in-depth
> strategy is that you use the least amount of CPU/resources to drop the
> most amount of spam. Each message that passes consumes additional
> resources to check it for rejection. Once you've assessed a message to
> get it all the way through the process, if it gets to the inbox,
> you're pretty sure it's a valid email.  Otherwise, it gets dealt with
> accordingly.

Right.
CPU is cheap. The problem w/r/t CPU is scaling up. And then there's
connect time when reaching out for verifications.

It's amazing to see how much spam gets through Google's outer layers
(winding up in the spam folder). Some of it might be due to web based
services trying to send email on behalf of the user. "Your friend just
pinned this shiny thing on Pintrest". Not that I give two bits for
Pintrest, but I can understand that sending actual email to his friend
is too much trouble for Joe Web Surfer Dude. So the receivers can't
always slam the door hard on SMTP.


On to Rob's reply ...

On 02/13/2017 12:07 PM, Rob Funk wrote:
> The initial length limit on TXT records is that a single "string" in a TXT 
> record is limited to 255 characters. However, multiple "strings" can be 
> concatenated together, up to a 64k limit. The other major limit that 
> applies (and is often a relevant factor for DKIM) is UDP; a DNS record 
> longer than 512 bytes won't fit in a UDP packet, requiring a retry in TCP. 
> Some DNS clients don't do TCP, and even among those that do, adding a TCP 
> handshake adds time to the query.

I'd forgotten about UDP packet size limit. duh



>> > Question: can I use DKIM with Postfix? or even with Sendmail? 
>> > Or what MTA do y'all use? 
> Yes you can, in fact with the same "milter" mechanism for both Postfix and 
> Sendmail. You set up a daemon like opendkim that understands how to filter 
> mail as a "milter", and tell Postfix/Sendmail to filter mail through it.

Anyone running Postfix at home with DKIM signing?


-- R; <><




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20170213/98311d16/attachment-0001.html