Re: [exim] support for domainkeys

----- Original Message -----
From: "David Brodbeck" <DavidB@???>
>> you could also check the message body for a special header added
>> by your mta and reject any bounce without that header, but at the
>> end all methods have they own problems.
>
> That probably won't work. Every MTA seems to have their own format for
> bounce messages, so you end up trying to parse an unknown quantity. Some
> don't even return the original message headers.
>

What if we try something akin to grey listing? As you probably know,
greylisting requires the maintenance of a database of some type, to store
"triplets" (sender addr, recipient addr, connecting IP, IIRC). I think the
following has already been suggested, not sure if exactly this way, but:

What if one saves similar outgoing triplets? (sender adder, recipient addr,
timestamp). Check incoming bounces to see if they correlate with any
outgoing triplets. If so, immediately remove the matching triplet, just in
case there are multiple copies on the way. (ick.)

Question: Is the IP a bounce returns from *certain* to be the same IP that
the mail was originally sent to? (I am willing to bet not). If not, then
there's no point in tracking the destination IP.

If a message is rejected at SMTP time (4xx or 5xx), do not enter it into the
database.

If a message is accepted at SMTP time, enter a record into the database.

For incoming bounces, search for database records in which bounce recipient
matches original sender field, and "intended to" addr matches original
destination field. If you find any matches, permit the bounce, and delete
the oldest matching record.

Regularly purge records older than some reasonable age, perhaps about a week
or two? How long is the longest (legitimate) bounce likely to take to
arrive?

The first problem I see is with aliases. What if the original recipient
gets aliased on the way, and the bounce arrives with the aliased name
specified as the original intended target?

What about bounces that have multiple recipients, due to multiple aliases on
the original sender addr?

Anyway, this is just a brainstorm. Pease poke holes at will. ;)

Maybe also add an MTA unique header to outgoing, which you could use to
allow bounces that have it, in spite of a failure of the above
"greybouncing" check. (i.e. passing either check will allow the bounce, but
failing both will reject it.)

Jim Roberts
Punster Productions, Inc.