On Tue, Feb 24, 2004 at 04:01:12PM -0500, Meng Weng Wong wrote:
| But after a quick scan, I can't see that it really discusses the SMTP
| envelope at all; nor what would be an appropriate action to take at a
| forwarding host or end-point host if a header were determined to be invalid.
| Bounce it I guess?
Caller-ID explicitly ignores the SMTP envelope.
Caller-ID's action is to silently sink the message. Bouncing is
definitely wrong because you know the sender is forged.
Not necessarily. The message might be non-forged but fail sender-id
validation for some reason *; in which case a bounce would get back. Silently
dropping messages on the floor because they fail some policy check is evil.
Besides, as you said, the sender address in the envelope is not related to
the From: header (which is what caller-id checks).
(* e.g. misconfiguration, the type of thing which bounces are explictly
there to detect)
Sinking is less
wrong, but because the sender never sees the bounce and the recipient
never sees the message, it reduces the integrity of the email system.
Rejecting at SMTP time is the only way to give the sender a chance.
This is why I consider SPF more FP-friendly; if SPF wrongly rejects a
message at least the sender gets a URL in the bounce message with
detailed instructions about how to reconfigure.
Sure. But you can reject with 550 after the DATA phase, rather than sink.
Many people in the Internet community feel this way; the designers of
Caller-ID perhaps discounted this concern in their design.
Seems so :-)
Furthermore, rejecting at the SMTP level *before* DATA saves bandwidth
and CPU.
True. It would be nice. But for a system to protect/validate the From:
header, you can't avoid downloading the message.
Although with some thought I think the called-id idea offers very weak
protection, it *does* at least try to address the right problem. DK may be
better in this regard.
I asked the list whether bandwidth was a cost to them, and consensus
appeared to be "yes". I believe the design behind Caller-ID implies
that bandwidth is not a significant cost.
I guess it's relative (to the cost of storage; the further CPU and bandwidth
costs of retrieval via POP3/IMAP/Webmail; and the costs to the end-user to
download and process)
I've been off-line for several days so will try to catch up on all current
threads before commenting more :-)
Regards,
Brian.