[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    [Bug 106580] New: Disposition notification request process doesn't
From:       Andreas Troschka <at.lists () om ! it ! eu ! org>
Date:       2005-05-31 23:49:59
Message-ID: 20050601014957.106580.at.lists () om ! it ! eu ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=106580         
           Summary: Disposition notification request process doesn't work if
                    different in/outbound addresses
           Product: kmail
           Version: unspecified
          Platform: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: kmail-devel kde org
        ReportedBy: at.lists om it eu org


Version:            (using KDE KDE 3.3.0)
Installed from:    Unlisted Binary Package
OS:                Linux

It is going to be a more and more spread use to have two different e-mail addresses \
(and accounts) one for the inbound (hidden by an alias address) and one for the \
outbound (not active for inbound, "unknown user"). This configuration stops SPAMmers \
to know your valid inbound addresses from getting them from the headers of your sent \
e-mails. It protects your privacy accordingly to the law of many countries.

But there is a problem with most MUAs (as with KMail) in handling such a setup due to \
the fact that the Disposition Notification process implementation is incomplete (see \
RFC2298).

Suppose:

two different addresses, one for inbound and one for outbound, each side

1. his.outb domain name------>[e-mail with DNR]------->your.inb yourdomain name
2. his.outb domain name<------[Ack of DNR]<------------your.outb yourdomain name

Actually when your MUA receives a DNR it takes the originating address and puts it \
into the To: field in the header of the aknowledgment e-mail it sends back to him. \
This is obviously rejected by "his" outbound box. So he will never receive the \
requested confirmation (Ack). 

Solution
--------

The Ack has to be sent to the address specified in his Reply-to: field instead:

1. his.outb domain name------>[e-mail with DNR]------->your.inb yourdomain name
2. his.inb domain name<-------[Ack of DNR]<------------your.outb yourdomain name


and if no address is specified in this field than, and only than, the address \
specified in the return-path field has to be used (this should be the last \
resource!).  Any reference at the From: field should be excluded due to the fact it \
often contains no or fake or outbound addresses!

Here the user operation sequence:

a)Open new mail composer
b)Write Destination address(es) in the fields To:, CC, BCC as needed 
c)Check "Disposition Notification Request"
d)Approve *proposed* Return-Receipt-To address (automatically taken from the address \
book for the destination address(es) specified) d2)Otherwise select from listbox or \
edit directly e)compose message text and send.

Andreas.
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


[prev in list] [next in list] [prev in thread] [next in thread]