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.
hm in r827xxx the disposition notification gets sent to the reply-to address... i think this is right?
It is basically correct. Therefore we have to pay attention to the situation where the sender doesn't specify any Reply-To: address. In this case the answering MUA can't find a Reply-To: field in the header so it usually gets the From: address to send the MDN response. This is inherently wrong as possible cause of SPAM due to the fact the From: field is freely editable by the sender. So a better choice, in case of missing Reply-To: address, is to get the address from the Returnpath: field.
Be it clear, the use of the Return-Path: field doesn't grant a correct delivery of the MDN response and in particular not in the issue presented with this bug. This because that address indicates the originating *outbound* address and not the inbound one. Therefore, a better implementation of the MDN process has to be made to get this "service" to work correctly and with the minimum SPAM risks.
i dont know enough to say something about this bug, so ill add a kmail dev as cc. i hope its ok.
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.