FWIW: unless the authentication mechanism is *not* tied to a specific physical device you still maintain an area for relatively simple exploitation (certs stored on user PCs is a good example). in practical terms this involves the submission of some identifying information in real time (password, secure-id value, etc.) of course, increases in assertion validity are met with [seemingly] exponential increases in effort/complexity.
also, my experience is that if someone has the wherewithal to spoof a mail name from the *local* network to perform nefarious activities, there is a good chance that they will be willing to sit down at another's machine to perform similar acts (besides, you have bigger fish to fry: internal human assets gone bad, *really* bad physical security or a significant breach in the network).
obviously, every implementation has its own level of risk/effort tolerance, so i just threw this out as what is acceptable for my needs.
caveat emptor!
b
alan.gerhard wrote:
bill -
nice work with the gateway matcherpairs btw - i set up a
variation of it last night ...
but it seems that the original inquery was to ensure beyond
doubt that a particular sender is authorized to send mail.
althoug your gateway more or less can ensure that the mail
originated from a network, it can't really ensure that the
sender actually has the authority to send.
this goes towards role based certs an dwhatnot, but a simple
acl can be used in conjunction with a custom MatcherPair to
validate the mails going out ...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
