Re: [Evolution] Re: mail options



If by return receipt you mean the Return-Receipt-To: header then this
should not be implemented under any circumstances.  Thankfully very few
MTAs handle this now because it is a serious security problem - for
example:-
      * Say I had put that header on this message.  However the address
        I put in there was not my address, but your address.  How many
        return receipts would you be getting from this list?  Say I had
        copied the original message to some of the *big* lists.
      * If I had put that header with a mailbox I own as the target I
        would now have the subscription address of all the list members
        (that would probably be a breach of EU Data Protection
        legislation, although working out who is the guilty party would
        be a problem).
      * I write a spamming worm of some sort.  Each message it sends has
        a Return-Receipt-To: header aimed at an anti-spam organisation.
Return-Receipt-To: was a serious problem more than 10 years back.  Its
not got any better.

Then do the following -
(a) ignore Return-Receipt-To if it differs from "Reply-To"
(b) ignore Return-Receipt-To if the messages is from a list (contains
"List-Id")
- most vacation notifiers already include such counter-measures and work
without incident.

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]