ietf
[Top] [All Lists]

Re: Engineering to deal with the social problem of spam

2003-06-07 16:28:10
and in this bof, i suggest that gateways to the current system be shat
upon and never again considered.  when we move, we'll MOVE.

That's not globally-applicable.

yes, it is.

Probably better to specify the gateway tagging, ...

and we're going to convey trust and credence through a nontrusted system How?

Indeed, some level of gatewaying will likely be necessary for transition, 

no, it's not.  i really mean it.

and to accomodate intra-company use of embedded devices which transmit 
email alerts (e.g. UPSs, NAS boxes, etc.).

let me explain what i mean, in case there's room for compromise.  ibcs will
have to be an end to end system.  there won't be MX RRs for RHS's, but 
rather SRV RRs for destinations -- almost exactly like SIP, i suspect.  so,
rather than the current logic of

        ($lhs, $rhs) = split /@/, $dest;
        @mxset = &lookup($rhs, 'MX');
        foreach $mx (sort { $a->prio <=> $b->prio } @mxset) {
                return 1 if &try($mx->host, 25);
        }
        return 0;

we'll see logic of the form

        (($srvname = $dest) ~= s/\./\\./go) ~= s/@/./;
        @ibcsset = &lookup("_ibcs._tcp.$srvname", 'SRV');
        foreach $srv (sort { $a->prio <=> $b->prio } @srvset) {
                return 1 if &try($srv->host, $srv->port);
        }
        return 0;

this means any destination needs a SRV RR.  instead of cracking 
paul(_at_)vix(_dot_)com
on the @ and looking for the MX RRset for vix.com, it'll get translated into
_ibcs._tcp.paul.vix.com and the SRV RRset will be used to find the possible
agents for this destination.

if smtp fallback is desired, it must be done in the sending user agent, who
upon not finding the SRV RR, could ask "try smtp instead?".  if there's a
NAT or firewall or gateway involved, then the submission protocol between
the user agent and local gateway has to have enough infowidth to express
these conditions and offer these choices.

the idea of an ibcs agent who nexthops through smtp is just right out, other
than because the user's own avatar decides to punch it through smtp to reach
a pager or something like that.

the idea of an smtp agent who can gain a sender's credentials in order to
make promises about mail that came from smtp and has to reach an ibcs
recipient is likewise nonsequitur.
-- 
Paul Vixie



<Prev in Thread] Current Thread [Next in Thread>