On Nov 29, 6:02pm, Alessandro Vesely wrote:
}
} John Levine wrote:
} > But it's tricky, since there is little standardization among signups
} > (particularly when one party is handling signups or sending for
} > another) and it's hard to come up with something with usable human
} > factors to verify that a putative signup actually happened.
}
} IMHO, it might be triggered at the SMTP forwarding level: An MTA knows
} it is replacing or exploding the recipient, and it may learn that the
} target MTA supports signup handshakes from its EHLO response. At that
} point it should lookup a local database to learn if it has already
} done the handshake, if it is currently underway, or if it may be
} initiated right now. In the first case (already), the db lookup may
} yield an id/passwd pair to use with SMTP AUTH.
Is it just me, or does this sound an an awful lot like ...
Simplest would probably be to model the base mechanism after the DSN
standard (RFC3461). Client sends EHLO, server responds that it will
accept postage. Client appends a parameter to the MAIL command with
the identity of its payment service(s). Server accepts or declines,
attaching an extended status code for details. Client then appends
to the RCPT command a parameter indicating how much the sender is
willing to pay for this message, and server accepts or declines,
again with an extended status indicating the charge the server wants
to deliver the message, regardless of whether it was declined.
We're just replacing postage with signup verification.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg