44
SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local mail daemon (MTA; e.g. sendmail or exim) MTA looks for ~/.forward file MTA pipes mail through .forward .forward decides what to do with mail Can call filter program procmail from .forward

SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

  • View
    223

  • Download
    1

Embed Size (px)

Citation preview

Page 1: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

SpamBGon + Unix email

The SpamBGon design allows integration with standard UNIX mail handling

UNIX mail processing looks like this: Remote sender -> local mail daemon

(MTA; e.g. sendmail or exim) MTA looks for ~/.forward file MTA pipes mail through .forward .forward decides what to do with mail Can call filter program procmail

from .forward

Page 2: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Putting the parts together Tell .forward to filter your mail through

the procmail program:|/usr/bin/procmail -f-

Set up a .procmailrc file with the following rules:# PATH must include javaPATH=/bin:/usr/bin:/usr/local/binMAILDIR=$HOME/mymaildir:0fw|java BSFTest -k stuff ...

:0:* ^X-Spam-Status: SPAMmy-spam-folder

Page 3: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

For More Info...

man procmail man procmailrc man exim man spamassassin

Page 4: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

A*

Page 5: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Basic Setup, Reprise

Puzzle game: set of states+moves Apply a move/action to a state to

generate a next state Group of all states reachable in some

single move from state s are the children/ successors of s

Whole thing forms a directed graph; possibly acyclic, but more usually possessing cycles

Every move associated with a cost: c(s,a,s’)=cost to go from s to s’ via a

Object: find min cost path from start to goal

Page 6: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

Goal

Page 7: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

GoalStates that have been visited; had all childrengenerated == “closed”

Page 8: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

GoalStates that have been generated, but notexamined; children not generated == “open”

Page 9: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

Goal“Open” set forms a “fringe” or “frontier”around closed set.

Page 10: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

GoalGenerating children for s moves it from opento closed and expands frontier. Adds its children to open.

s

Page 11: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

Goal

s

Length of shortest path from start to s: g(s)

Page 12: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

Goal

s

Length of shortest path from start to s: g(s)

Note! May bemultiple paths to s --not guaranteed thatfirst path to s isshortest path to it!

Page 13: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

Goal

s

Estimated shortest dist froms to goal == h(s)(this is the heuristic function)

h(s)

Page 14: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Some Terminology

Start

Goal

s

g(s)+h(s)=f(s)Estimated total cost fromstart to goal

h(s)

Page 15: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Search Strategies

Closed list (set) things can be ignored Hard problem: which open list (set) thing

do we examine next? Strategies:

Smallest h(s)

Page 16: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Search Strategies

Closed list (set) things can be ignored Hard problem: which open list (set) thing

do we examine next? Strategies:

Smallest h(s) -- “greedy” search

Page 17: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Search Strategies

Closed list (set) things can be ignored Hard problem: which open list (set) thing

do we examine next? Strategies:

Smallest h(s) -- “greedy” search Smallest g(s)

Page 18: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Search Strategies

Closed list (set) things can be ignored Hard problem: which open list (set) thing

do we examine next? Strategies:

Smallest h(s) -- “greedy” search Smallest g(s) -- Breadth-first search

(BFS)

Page 19: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Search Strategies

CLOSED list (set) things can be ignored Hard problem: which OPEN list (set) thing

do we examine next? Strategies:

Smallest h(s) -- “greedy” search Smallest g(s) -- Breadth-first search

(BFS) Ignore h() and g(); just take things off

OPEN in LIFO order

Page 20: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Search Strategies

CLOSED list (set) things can be ignored Hard problem: which OPEN list (set) thing

do we examine next? Strategies:

Smallest h(s) -- “greedy” search Smallest g(s) -- Breadth-first search

(BFS) Ignore h() and g(); just take things off

OPEN in LIFO order -- Depth-first search (DFS)

Page 21: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Search Strategies

CLOSED list (set) things can be ignored Hard problem: which OPEN list (set) thing

do we examine next? Strategies:

Smallest h(s) -- “greedy” search Smallest g(s) -- Breadth-first search (BFS) Ignore h() and g(); just take things off

OPEN in LIFO order -- Depth-first search (DFS)

Smallest f(s) -- “Algorithm A”

Page 22: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

From “A” to “A*” Unless we add additional conditions,

Algorithm A is not guaranteed to do any better than anything else

Recall roll of h(s) -- the heuristic Estimate of smallest cost from s to goal

We will restrict h(s) to be admissible Defn: Let h*(s) be the true min cost to

goal Defn: Heuristic h(s) is admissible iff

h(s)≤h*(s) s An admissible heuristic is an underestimate

of how hard it is to get to the goal -- optimistic

Algorithm A + admissible h() -> A*

Page 23: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

From A* to Dijkstra’s A* guarantees:

When the goal is first opened, we will have the shortest path to the goal

I.e., as soon as you find the goal, you can stop and know you have the optimal path

Does not guarantee that you have the shortest path to any other node

Need additional constraint on heuristic Defn: Iff h(s)≤c(s,a,s’)+h(s’) then h(s) is

monotonic (a.k.a., consistent) A* + monotonic heuristic Dijkstra’s alg Guarantees that first path to any node is

shortest

Page 24: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Exercise

For the 15-puzzle (4^2-1) c(s,a,s’)=1 a, s s’ Examine the following heuristics: are they

admissible? Monotonic? Are they equivalent to other things you’ve seen? h(s)=0 s h(s)=37.2 s h(s)= s h(s)=“# tiles out of place” s

Can you construct an admissible, but non-monotonic heuristic?

Page 25: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Keeping Track...

Problem: if h() is not monotonic, can’t guarantee that you’re truly finished with anything on CLOSED

Might be able to find something a second time by a shorter path

Page 26: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Keeping Track...

Start

Goal

Page 27: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Keeping Track...

Start

Goal

s

Page 28: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Keeping Track...

Start

Goal

s

Page 29: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Keeping Track...

Start

Goal

s

Page 30: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

Keeping Track...

Problem: if h() is not monotonic, can’t guarantee that you’re truly finished with anything on CLOSED

Might be able to find something a second time by a shorter path

Could have better path to something on CLOSED or on OPEN

Have to update that node with new “best path” to it Also have to handle all children!

How?

Page 31: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece

CLOSED={}; OPEN={ START }

Page 32: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece CLOSED={}; OPEN={ START } while (!OPEN.isEmpty())

s=OPEN.getFirst();

Page 33: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece CLOSED={}; OPEN={ START } while (!OPEN.isEmpty())

s=OPEN.getFirst(); if (s.goalP()) { return path-to-s; }

Page 34: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece CLOSED={}; OPEN={ START } while (!OPEN.isEmpty())

s=OPEN.getFirst(); if (s.goalP()) { return path-to-s; } cIter=s.children();

Page 35: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece CLOSED={}; OPEN={ START } while (!OPEN.isEmpty())

s=OPEN.getFirst(); if (s.goalP()) { return path-to-s; } cIter=s.children(); while (cIter.hasNext())

Page 36: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece CLOSED={}; OPEN={ START } while (!OPEN.isEmpty())

s=OPEN.getFirst(); if (s.goalP()) { return path-to-s; } cIter=s.children(); while (cIter.hasNext())

child=cIter.next();

Page 37: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece CLOSED={}; OPEN={ START } while (!OPEN.isEmpty())

s=OPEN.getFirst(); if (s.goalP()) { return path-to-s; } cIter=s.children(); while (cIter.hasNext())

child=cIter.next(); if (CLOSED.contains(child)) {

if (child.heuristic() < CLOSED.get(child).heuristic())

Page 38: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece CLOSED={}; OPEN={ START } while (!OPEN.isEmpty())

s=OPEN.getFirst(); if (s.goalP()) { return path-to-s; } cIter=s.children(); while (cIter.hasNext())

child=cIter.next(); if (CLOSED.contains(child)) {

if (child.heuristic() < CLOSED.get(child).heuristic()) {

// remove child from CLOSED; // insert child into OPEN; // discard version from CLOSED. // Why?

}

Page 39: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece CLOSED={}; OPEN={ START } while (!OPEN.isEmpty())

s=OPEN.getFirst(); if (s.goalP()) { return path-to-s; } cIter=s.children(); while (cIter.hasNext())

child=cIter.next(); if (CLOSED.contains(child)) {

if (child.heuristic() < CLOSED.get(child).heuristic()) {

// remove child from CLOSED; // insert child into OPEN; // discard version from CLOSED. // Why?

} else { // discard child and cont }

}

Page 40: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece else if (OPEN.contains(child))

if (child.heuristic() <

OPEN.get(child).heuristic()) {

Page 41: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece else if (OPEN.contains(child))

if (child.heuristic() <

OPEN.get(child).heuristic()) { // remove prev version of child from // OPEN and insert new child }

Page 42: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece else if (OPEN.contains(child))

if (child.heuristic() <

OPEN.get(child).heuristic()) { // remove prev version of child from // OPEN and insert new child } else { // discard child and continue }

}

Page 43: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece else if (OPEN.contains(child))

if (child.heuristic() <

OPEN.get(child).heuristic()) { // remove prev version of child from // OPEN and insert new child } else { // discard child and continue }

} else { // child not on OPEN or CLOSED OPEN.insert(child); }

Page 44: SpamBGon + Unix email The SpamBGon design allows integration with standard UNIX mail handling UNIX mail processing looks like this: Remote sender -> local

The Algorithm, Piece by Piece else if (OPEN.contains(child))

if (child.heuristic() <

OPEN.get(child).heuristic()) { // remove prev version of child from // OPEN and insert new child } else { // discard child and continue }

} else { // child not on OPEN or CLOSED OPEN.insert(child); }

CLOSED.insert(s);