In <[EMAIL PROTECTED]> Steve Atkins <[EMAIL PROTECTED]> writes:
> I guess that the real question is what's the difference between "I > always sign" > and "I always sign and I get phished"? > > The impression I'm getting, from several people, is that "I always > sign" is already > being written off as likely to be ignored by recipients and that > there needs to be > a "No, I really mean it!" modifier? I've said before that I can see some value, not a huge amount, but certain some value, in distinguishing between: 1) I always sign, but I also know that I send email through relays that will break the signature. and 2) I always sign, and I also do not knowingly send email through relays that break signatures. Case 1) is for folks that let their users send email to mailing lists and such, while case 2) is for folks that are really worried about phishing and such and are willing to take the necessary steps to that email with missing/broken signatures can be rejected. Thinking about it more, I've decided that maybe the clearer distinction is: 1) I always sign, but I also know that I send email through relays that will break the signature. If you, as a receiver, reject legitimate email due to broken/missing signatures, it is your fault and I'll place the blame on you. 2) I always sign, but I also do not knowingly send email through relays that break signatures. If you, as a receiver, reject legitimate email due to broken/missing signatures, it is my problem and you can place the blame on me. In theory, a receiver of case 1) signing can use the "I sign all" information, along with other information the receiver knows about the source of the email (is it a known mailing list? etc.) to make a reasonable guess about whether a broken/missing signature is a good spam indicator or not. In theory, a sender of case 2) can take steps, including no longer sending email to certain users/domains/relays, to make sure that they can continue to advertise this stricter sending policy. -wayne _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
