From: Ronald F. Guilmette (rfgmonkeys.com)
Date: Fri Dec 01 2006 - 18:21:25 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

In message <6244B9E1-19D3-44F7-A48B-E805A1398F35adam.gs>,
Adam Jacob Muller <lists-postfixadam.gs> wrote:

>I think his idea, which seems interesting to me, is one of "did I do
>anything that might trigger this bounce." Doing so would require
>maintaining a database of some kind of unique characteristics of sent
>mails in order to check all incoming bounces.

No, not really. Thing don't need to be that complicated.

My (trivial) plan is that for each local mail user... which in my case
here always corresponds to some actual UNIX "user" account (i.e. an entry
in /etc/passwd)... a smallish data base will be maintained for that user
of _all_ of the e-mail addresses that he's sent e-mail to. That's his
whitelist. If anybody on his whitelist sends him any kind of automated
bounce, or any kind of automated response at all, it will be let in.
It's just that simple.

Now, you may well ask: "How is personal whitelist for each local mail
user created and maintained, over time?"

The answer is that I _was_ thinking about building my own "shim" which
would be a kind a pseudo-daemon that would sit in-between local mail
clients and the actual local mail server's "submission" port, and then
I _was_ going to have that shim update the appropriate local user's
personal whitlist each time any given local user sent a piece of outbound
email, _however_, I've realized today that I don't need an SMTP "shim"
of the kind I was thinking of, because I can instead just build a Postfix
"policy server" and have it take care of keeping the local per-user whitelists
always up-to-the-minute. Given that a Postfix policy server is passed the
sender and recipient address for each message that passes through Postfix,
it ought to be a relatively simple matter for me to code up a policy server
that just grabs those two data items (sender address, recipient address),
lops off the (local) domain part of the former, and then uses the resulting
"local part" (local user ID) as a directory name (relative to /usr/home),
then appends a suffix of "/.whitelist.db". That gets me a full pathname of
the specific per-user whitelist database file to update. So then I can just
have the "policy server" add the current recipient address to that data base.
Ta da! Now I have nice per-user whitelists that are kept always up-to-date
in (mostly) real-time.

Oh sure, you could get a lot fancier than this. You could go further and
try all sorts of magic to try to correlate inbound In-Reply-To value
with prior outbound Message-IDs, but why bother? Doing so would just
create a hell of a lot more overhead, and in practice wouldn't buy you
much, if anything at all.

I mean think about it. When you receive what I call "unsolicited backscatter",
what percentage of that crap actually comes to you from e-mail addresses of
people that you yourself actually _have_ sent e-mail to, i.e. at _any_ time
in your entirely lifetime? About 0.0001% ? Yes.

99.9999% of the unsolicited backscatter that _I've_ ever received has come
from people and e-mail addresses that I have never heard of, that I've got
no connection with, and that I've n_never_ sent any e-mail to.

>What about message IDs?
>They seem to be replicated in bounces,

Sometimes, but not nearly as often as any of us would like. (I looked
into this already.)

Believe me, I'd become a terrorists and join Al Quada if I believed that
by doing so, I could somehow force everyone on planet earth to start
always using In-Reply-To: headers for _all_ bounces and also for all
"vacation" type autoresponders. But even me converting to Jihad wouldn't
cause all homo sapiens to finally "get with the progam", as it were, so I
guess I'll just skip it. (Basically the problem of getting *everyone*
on planet earth to start obeying sensible e-mail protocol rules... either
next week or even in our lifetimes... is, depending on your point of view,
either (a) NP complete, or else (b) functionally equivalent to the problem
of hearding cats, or else (c) both of the above.)

(I'd love it if we had an official RFC that said that every kind of thing
that can generate an automated e-mail response to some incoming e-mail
message MUST include In-Reply-To: headers on the messages that it sends,
but even if some dedicated schmuck who has a helluva lot more time on his
hands than me were to shepard such an RFC, successfully, through the whole
RFC process, how many decades would it be before even 80% of everybody
actually started obeying it?)

>It seems easy enough to define 2 milters, one for incoming and one
>for outgoing. The outgoing milter would add the message ID of the
>mail to a database,

See above.

Two milters... or better yet just a single inbound/outbound policy server...
yes. But as regards to the Message-ID stuff you proposed, that part is
totally unnecessary. All that's needed is to record all of the recipient
e-mail _addresses_ that each "local" e-mail user sends outgoing mail to.

Regards,
rfg

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]