It looks like the headers sent to a new subscriber are the same as what may be saved in the message itself. So, if you change any list settings, like the list name, or list owner, they won't be reflected in that message being sent.

The f=profile_login screen shows input fields which are badly vertical aligned:

Adding "margin-top:-5px;" to these input fields will correct this, the same way as already done with:

input.full {
width:95%;
margin-top:-5px;
}
input.midi {
margin-top:-5px;
width:50%;
}

from default_css.css.

Also I would like to see these input fields much wider otherwise even a short email address like [email protected] cannot be shown at once.

uhuh.

one small thing I noticed, it said mirgration from 3.0 to 3.1 - i though i opened the wrong file but looking in the code - (

print h1($DADA::Config::PROGRAM_NAME . ' 3.0 to 3.1 Migration Assistant ');

)

Regards

And that's pretty sad,

What happens, is, you just get redirected to the, "view list" screen. There's an error that (may) get shown, but it's not.

uhuh.

The subscriber field values for the subscriber when a, "unsubscribed!" message is never filled in - even though it is for the, "subscribed!" message.

This is because there's nothing in Dada Mail to grab information about a subscriber that doesn't exist. A hack could be put in place to get this info from other sources.

Sometimes, if this subroutine is run, you'll get this error:

[Sun Dec 13 18:37:48 2009] dada_bounce_handler.pl: dada_bounce_handler.pl - irrecoverable error processing message. Skipping message (sorry!): Can't call method "head" on an undefined value at /var/www/cgi-bin/dada/plugins/dada_bounce_handler.pl line 3607, line 292791.

This error is because of a missed dereferencing of a variable. Silly, dumb, mistake.

You may get an error in the sending preferences screen that says either,

Disabled. The Net::SMTP::SSL module needs to be installed.

or,

Disabled. The IO::Socket::SSL module needs to be installed.

This seems to be because Dada Mail ships with a Perl-only version of Scalar::Util and List::Util - it really shouldn't. There's things that only the XS version allows you to do.

Open discussion lists (accepting mail from someone who is not on the list)
seems to be broken in 4.0.1 (worked OK in 3.x). I've set
"Allow_Open_Discussion_List" to 1 in the plugin itself, in my external
.dada_config and in Config.pm and checked that it shows as enabled in
Plugins/Discussion Lists/View All Plugin Configurations.

There is no failure message in the usage logs or error logs - a message
sent to the list just silently disappears. But if I click the Manually
Check and Send Waiting Messages button in dada bridge (before the cron job
runs and the message disappears) I can see it fails due to being
not_from_list_member and not_from_authorized_subscriber. It seems to be
100% reproducible.

This is essential functionality for me because committee members often send
to the list from work addresses I don't know about. They've stopped using
the list because it "never works".

If the black list is turned on and someone unsubscribes, they'll be added to the blacklist.

If they are resubscribed and unsubscribe (again), they will (again) be added to the blacklist.

Meaning, two separate entries.

Sigh.

This relates to a bug I had reported on 2009-12-24. I do have 4.02 Pro installed.

Here is a similar issue where the from is the list address itself, shouldn't have gone through...

Neither [email protected], or [email protected] are on the network list.

From [email protected] Wed Feb 17 17:45:27 2010
Received: from <tmpl_var LEFT_BRACKET>201.94.162.134<tmpl_var RIGHT_BRACKET> (port=1357 helo=OAWEPGWF)
by vps2033.inmotionhosting.com with esmtp (Exim 4.68)
(envelope-from [email protected])
id 1NhvRU-000696-Uc; Wed, 17 Feb 2010 17:45:27 -0800
Received: from 201.94.162.134 by ns.ccu.cz; Wed, 17 Feb 2010 22:44:12 -0300
Message-ID: 000d01cab03b$def90060$6400a8c0@annotatingk78
From: "Microsoft Team" [email protected]
To: [email protected]
Subject: Conflicker.B Infection Alert
Date: Wed, 17 Feb 2010 22:44:12 -0300
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0006_01CAB03B.DEF90060"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Status: No, score=1.0
X-Spam-Score: 10
X-Spam-Bar: +
X-Spam-Flag: NO

http://dadamailproject.com/support/boards/viewtopic.php?f=5&t=1768&p=6757#p6757

* Report this post
* Reply with quote

Another 3 -> 4 migrating problem

Postby WouterM » Wed Dec 23, 2009 1:08 pm
Hi,

I have encountered a weird problem after upgrading to version 4. Everything works fine except for the "Use One SMTP Connection per Batch (Experimental)" feature. I can not select it because "SMTP Sending is disabled." Yet when I look at the Sending Preferences, it says "Messages are currently being sent via SMTP using SMTP server, mail.****************.com." These two messages do not add up.

Kind regards,

W

WouterM

Posts: 13
Joined: Thu Sep 24, 2009 1:18 pm

Top

* Edit post
* Report this post
* Reply with quote

Re: Another 3 -> 4 migrating problem

Postby justin » Thu Dec 24, 2009 1:08 pm
It looks like that message, "SMTP Sending is disabled." is there shows up, if you're using SMTP sending or not - that's a bug for sure, but even if SMTP is selected or not, I can still select and change that setting (Use One SMTP Connection per Batch (Experimental)) You can't?

• Justin J, Lead Dadaist for Dada Mail
  Support Dada Mail by Going Pro!.

User avatar
justin

Posts: 2210
Joined: Wed Feb 13, 2008 8:41 pm
Location: Denver, CO

    * Website

Top

* Report this post
* Reply with quote

Re: Another 3 -> 4 migrating problem

Postby WouterM » Fri Dec 25, 2009 12:17 am
I can select it but when I hit save it comes back unselected again.

WouterM

Posts: 13
Joined: Thu Sep 24, 2009 1:18 pm

Top

* Edit post
* Report this post
* Reply with quote

Re: Another 3 -> 4 migrating problem

Postby justin » Sun Dec 27, 2009 1:56 am
I'll add this to the issues and see if I can't make a fix, for the next release,

In Dada Bridge, you can't change the Spam Assassin level to check. There's just no popup menu.

And, if it's not, it never shows up (really) in the interface and if you save or save and test, it'll get written over in the tests, and you'll bang heads on things.

The following vars from Config.pm cannot be overrided by a custom .dada_config because the || (OR) are missing:

$LIST_CONFIRM_PASSWORD_MESSAGE_SUBJECT = '[etc]'
$LIST_CONFIRM_PASSWORD_MESSAGE = <<EOF [etc]

$LIST_RESET_PASSWORD_MESSAGE_SUBJECT = '[etc]'
$LIST_RESET_PASSWORD_MESSAGE = <<EOF [etc]

If I press the, "Save, Then Test..." Button (rather than just the save button) the POP3 username and password don't save. If I press just the "Save" button, they're saved.

Another templating bobble.

You'll get things like this:

CREATE TABLE IF NOT EXISTS dada_profile_fields_attributes (
attribute_id int4 not null primary key auto_increment,
field varchar(320),
label varchar(320),
fallback_value varchar(320),
-- I haven't made the following, but it seems like a pretty good idea...
-- sql_col_type text(16),
-- default mediumtext,
-- html_form_widget varchar(320),
-- required char(1),
-- public char(1),
CONSTRAINT UNIQUE (field)
)
Problem executing query:
cannot do statement! BLOB/TEXT column 'field' used in key specification without a key length
at dada3_to_dada4_sql.pl line 113

Looks like there's a small problem in the template code...

Sometimes, the POP3/SMTP passwords (anything using CyberSaber to make a 2-way hash) will become corrupted, if you attempt to save the info. Very frustrating, when attempting to test POP or SMTP stuff

uhuh.

Looks like there's a problem in the template, where the value is never passed in the template. Easy fix!

Moderation is broken on Dada Bridge. The, "safely_encode" and, "safely_decode" subroutines in DADA::App::Guts are never exported, since we tell the SimpleModeration package not to, ala:

 use DADA::App::Guts qw(!:DEFAULT);

There are also other issues that disallow the moderation to work correctly.

They can currently also contain higher bit characters. This probably would just create an error upon list creation, if nothing else.

November and December are in the wrong location.

When a subscriber subscribes themselves, no record of the actual subscription is logged in the usage log. It probably should be logged.

Seems to be an error in the javascript,

If there's slashes in the pin, it's possible the pin itself won't be accepted by Dada Mail. The newest example has two slashes (//) together.

[Sun Apr 11 08:20:03 2010] [error] [client 203.206.129.129] [Sun Apr 11 08:20:03 2010] auto_pickup.pl: Use of uninitialized value in numeric eq (==) at ..//DADA/Mail/Send.pm line 138.
[Sun Apr 11 08:20:03 2010] [error] [client 203.206.129.129] [Sun Apr 11 08:20:03 2010] auto_pickup.pl: Reloading message... at ..//DADA/Mail/MailOut.pm line 1692
[Sun Apr 11 08:20:03 2010] [error] [client 203.206.129.129] [Sun Apr 11 08:20:03 2010] auto_pickup.pl: Use of uninitialized value in numeric eq (==) at ..//DADA/Template/Widgets.pm line 1871.

[Sun Apr 11 09:20:02 2010] [error] [client 203.206.129.129] [Sun Apr 11 09:20:02 2010] auto_pickup.pl: Use of uninitialized value $encstr in substitution (s///) at ../DADA/perllib/MIME/EncWords.pm line 294.
[Sun Apr 11 09:20:02 2010] [error] [client 203.206.129.129] [Sun Apr 11 09:20:02 2010] auto_pickup.pl: Use of uninitialized value $encstr in substitution (s///) at ../DADA/perllib/MIME/EncWords.pm line 295.
[Sun Apr 11 09:20:02 2010] [error] [client 203.206.129.129] [Sun Apr 11 09:20:02 2010] auto_pickup.pl: Use of uninitialized value $encstr in scalar assignment at ../DADA/perllib/MIME/EncWords.pm line 303.
[Sun Apr 11 09:20:02 2010] [error] [client 203.206.129.129] [Sun Apr 11 09:20:02 2010] auto_pickup.pl: Use of uninitialized value $encstr in length at ../DADA/perllib/MIME/EncWords.pm line 305.

See my post under mdegive in your forum "mail.cgi maxes cpu."

http://dadamailproject.com/support/boards/viewtopic.php?t=1999&amp;p=7723

I found out what causing the cpu to go to 100%. "View Archive".

I use Mysql. I can look at the archive table, only has 1100 entries, yet as soon as you hit that menu, it maxes the cpu and the page is never displayed.

I use the latest 4.0 version.

It would be better if:

• The subscriber list was an attachment, not just inline
• The attachment was named with a, ".csv" file ending, so it could be opened via one-click into a spreedsheet application

Currently, the information has to be copied and pasted into a text file, saved with a , ".csv" ending and then opened into a spreedsheet app. Argh!

This is a problem, if you don't have a DBM package installed. there's really no need for it to do this.

list short names should only be able to contain printable ascii characters, numbers and underscores.

They can currently hold higher bit characters as well

...and these links may be triggered automatically by web spiders. Causing all sorts of trouble.

If you have a large number of awaiting schedules, the order that which they are listed in Beatitude is based, probably, on the date of creation, instead of something my useful, like the date of the next mailing - it would be better to index them on that, than on date of creation, which doesn't have any real relationship with the scheduled mailing (or it's DOA).

pin "numbers", like in the subscription process sometimes have '/''s - which is fine, but it does seem like it they're the first character in the pin, "number", it breaks the pin number and the subscription, for example, will fail.

When the legend of a fieldset is present, the grey background color bleeds out of the fieldset box when using Internet Explorer. This is a known bug in IE, see: http://social.msdn.microsoft.com/Forums/en/iewebdevelopment/thread/53876982-02c8-406e-a900-423803d5780c

Fortunately it can be fixed by dissociating the legend tag from the normal flow of the document, see http://www.mattheerema.com/web-design/2006/04/getting-fieldset-backgrounds-and-legends-to-behave-in-ie/

Therefore I have added the following code to default_list_templte.tmpl and default_admin_template.tmpl just before the tag to correct the problem:

<!--[if IE]>
<style type="text/css">
legend{
position:absolute;
top: -.5em;
left: .5em;
line-height:1.1em;
}

fieldset{
position: relative;
margin-top:2em;
padding-top:.75em;
padding-bottom:0px;
}

</style>
<![endif]-->

Tested on Internet Explorer, Firefox, Safari, Opera, Chrome.

You can cause a double subscription using the List Invitation Feature, simply by sending 2 list invites to the same address and having the address be confirmed after the second time.

Here's what giving problems:

Return-Path: <>
Delivery-Date: Thu, 07 May 2009 11:03:07 -0400
Received-SPF: pass (mxus6: domain of mout-bounce.perfora.net designates
74.208.4.198 as permitted sender) client-ip=74.208.4.198;
[email protected];
helo=mout-bounce.perfora.net;
Received: from mout-bounce.perfora.net (mout-bounce.perfora.net
[74.208.4.198])
by mx.perfora.net (node=mxus6) with ESMTP (Nemesis)
id 0MKorw-1M257r1AOh-0001Ph for [email protected]; Thu, 07 May 2009 11:03:07
-0400
Received: from mout by mous0.kundenserver.de id 0MKp0C-1M256t0XaG-000NMl;
Thu, 07 May 2009 11:02:07 -0400
Date: Thu, 07 May 2009 11:02:07 -0400
From: Mail Delivery System <[email protected]>
To: [email protected]
Subject: Mail delivery failed: returning message to sender
Message-Id: <[email protected]>
X-Original-Id: 0MKp8S-1M256p3PJt-000g9f
Envelope-To: [email protected]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of
its recipients. The following addresses failed:

<[email protected]>

SMTP error from remote server after RCPT command:
host mx1.hotmail.com[65.55.37.88]:
550 Requested action not taken: mailbox unavailable


--- The header of the original message is following. ---

Received: from infong488.perfora.net (infong488.lxa.perfora.net
[74.208.16.29])
by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis)
id 0MKp8S-1M256p3PJt-000g9f; Thu, 07 May 2009 11:02:05 -0400
Received: from 115.133.212.224 (IP may be forged by CGI script)
by infong488.perfora.net with HTTP
id 3oUdm4-1M256p2vdC-0007MU; Thu, 07 May 2009 11:02:03 -0400
X-Sender-Info: <[email protected]>
Precedence: bulk
Date: Thu, 07 May 2009 11:02:03 -0400
From: "Sivananda" <[email protected]>
To: "Sivananda Subscriber" <[email protected]>
Reply-To: "Sivananda" <[email protected]>
X-Priority: 3
List: gurudev
List-Archive:
<http://www.dlshq.org/cgi-bin/dada/mail.cgi/archive/gurudev/>
List-ID: <gurudev.infong488.schlund.de>
List-Owner: <[email protected]>
List-Subscribe: <http://www.dlshq.org/cgi-bin/dada/mail.cgi/s/gurudev/>
List-Unsubscribe: <http://www.dlshq.org/cgi-bin/dada/mail.cgi/u/gurudev/>
List-URL: <http://www.dlshq.org/cgi-bin/dada/mail.cgi/list/gurudev/>
Message-ID: <[email protected]>
X-Mailer: Dada Mail 3.0.2
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
MIME-Version: 1.0
Subject: Sivananda Day-to-day (410)
X-Provags-ID: V01U2FsdGVkX1/VJ3qhgR9rnHKUAaSAA11Mdgwdn162xLtfNoF
oM3acTU58XOSdHRK7SstXBVsBiEF2RwdFaGY4JdvnpemWLhNmM
3BUqZHuFB0=

"Soft_Max_Size_Of_Any_Message" plugin variable should be included - it looks like it was just forgotten.

Looks like a problem with DADA::Profile and the SQL backend...

What it be hard to make this so it gives back something helpful?

Sometimes, in none mass-mailing messages, no "List-Unsubscribe" header will appear.

We run version 3.0 pro. Today 2 of our mailing list go spammed by somebody
impersonating somebody else, look at the from below:

From: [email protected] <[email protected]>

[email protected] is allowed to mail to the list but the real email address
is [email protected] which is not on the list.

This should have not gone through.

It seems that sometimes the archived messages aren't templated out - especially if you're using new-style tags, since the characters:

<

and,

(amongst others)

Are turned into their HTML entity, before being fed to the template parser.

Archives don't correctly template out tags using fallback variables

That's because, the fallback variables are never given to HTML::Template correctly.

Pretty big glaring f'n issue.

This probably affects everything using fallback variables - that feature is essentially broken

I can't even believe there isn't even a test to test this. Ugh.