Actually, you could implement this already much cleaner using spam 
reporting. You can then extract from the message whatever you want, 
and spam filtering is magic art for most users anyway.

Blacklist/whitelist to me is a shortcut for blacklisting from 
addresses, not return-path.  There may be instances where return-path 
is more correct, but there may very well be instances where from is 
more correct.



This seems like a minimally useful feature for most users.  I would 
rather see this maintained as a patch on the wiki or, alternatively, a 
[black|white]list hook being created.

Beside my general concerns, why does this have to specified per 
server? Sounds like it makes much more sense as a global configuration.

Using blacklists for spam is silly; spammers will change their from 
headers, etc too often to be useful.



But if this catches mailings using VERP or whatever that make the 
envelope headers useless, then I guess it sounds useful to have access 
to this other field.

Chuck - Attached patch which uses $_SESSION instead of a loop.



Matt - Well, it's for any case where the SMTP envelope sender (which 
ends up in the Return-Path header) differs from the From header value. 
In order of prevalence, our users seem to use message blacklisting 
mostly for semi-spam bulk mailings, then for actual spam messages that 
slip through Spamassassin for whatever reason, then for pesky humans 
using poorly configured MTAs or doing other ill-advised things.



The current system is almost entirely useless for us right now as bulk 
mailings and spam seem to rarely have the same SMTP envelope sender & 
from.

This sounds pretty obscure and intransparent for the end user to me.

Is this for blocking spam messages or specific pesky humans?

Do any other developers have an opinion on this?



To Ryan - can you update patch to use the server info from the session 
instead of looping through $servers every time through the wblist loop?

Would making the custom header field (in our case Return-Path) 
viewable in the standard limited headers view make this more 
acceptable? Not sure where it would fit, maybe under the 'From' 
header? For the message list view, it could be added to the 'From' 
tooltip. It would only show this extra info if the wblist_header is 
being used and its content differs from that of the 'From' field.



Our backend looks at the SMTP envelope senders rather than the 'From' 
headers, so the current functionality of the Whitelist/Blacklist 
system isn't cutting it.

This seems very confusing to me UI-wise, as the Return-Path header 
isn't even displayed in most views.

This patch puts an optional config "wblist_header" into servers.php. 
Specifying an email header field here will use that for adding to the 
Whitelist/Blacklist. For instance, in our situation we have found that 
using the "Return-Path" header field is better than using "From". So 
when the user click Whitelist/Blacklist in an email it will add the 
email address in the "Return-Path" header field to the users custom 
list.



If the config option is not used, it will have the same behavior as 
before. If the config option is used but with a non-existent header 
field, it will throw out a notification and not add any email address.