#2432 listcommands mailout doesn't like default identity


There's a bug here, but it probably takes a combination of circumstances to make it happen. Patch below for SM 1.4.9a.

For a mailing list with an email unsubscribe link, listcommands creates a special compose window. Since I have multiple identities, the window contains a dropdown with all my identities. If I leave things as-is (accepting the default identity), that identity is not actually used when sending the message. If I select an alternate identity, it is used as expected.

The reason I know the default identity is not used is because the sending fails in my environment. The error message is a response from my local SMTP server telling me it doesn't like the sender address. The sender address is the SM login name and the default domain from my SM config. (In my environment, login IDs are different from email localparts.)

SOLUTION: Here is where I think the problem lies. In a normal compose window, the select dropdown for identities (ie, the "identity" form field) uses a value of "default" for the default identity. The compose screen for unsubscribe uses a value of "0". The post target compose.php knows how to deal with a value of "default" but doesn't know how to deal with a value of "0". (I haven't followed through the code in compose.php ... I'm just speculating.)

Here is a patch for mailout.php for SM 1.4.9a which implements this fix:

--- plugins/listcommands/mailout.php-DIST 2006-02-03 14:27:52.000000000 -0800
+++ plugins/listcommands/mailout.php 2007-02-19 11:21:38.000000000 -0800
@@ -63,7 +63,13 @@
if (count($idents) > 1) {
echo '<select name="identity">';
foreach($idents as $nr=>$data) {
- echo '<option value="' . $nr . '">' .
+ if ($nr == "0") {
+ $optionvalue = '<option value="default">';
+ }
+ else {
+ $optionvalue = '<option value="' . $nr . '">';
+ }
+ echo $optionvalue .
$data['full_name'].' <'.
$data['email_address'] . ">\n");


  • Thijs Kinkhorst

    Thijs Kinkhorst - 2007-02-22
    • assigned_to: nobody --> kink
  • Thijs Kinkhorst

    Thijs Kinkhorst - 2007-02-27

    Logged In: YES
    Originator: NO

    compose.php was using legacy code. The identities code has been centralised in functions/identity.php quite some time ago but compose.php wasn't adapted yet. I've changed compose to use that, reducing code and solving this bug at the same time.

  • Thijs Kinkhorst

    Thijs Kinkhorst - 2007-02-27
    • status: open --> closed-fixed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks