ELK M1XEP email revealed

I spent the morning screwing around trying to get the email to work.  I finally got it to work, but not the way I really wanted it to.  The main issue is that there's no way to diagnose the problem if the email doesn't get sent.  Several times I was pretty sure I wasn't even making a TCP connection to the email server but had no clue why.  I could connect from the CMD line, but not from the XEP.  Turns out I didn't have a DNS server configured in the XEP.  When you do get a connection, the email server will spit out errors, but there's no way to know what they are from the XEPs viewpoint.
 
I also ran into some weird errors while email testing.  RP2 would try to send the email and the XEP would disconnect from the control.
Message box: System did not respond.  Connection may have been terminated.  (you think?) [Cancel] [Retry]
Message box: Control has disconnected [OK]
Turns out that's a known issue when the XEP isn't configured properly for email or "gets confused".
 
During my pursuit, I cobbled up a program to simulate a sendmail server and had the ELK send to it.  This was designed to mimic my server running qmail.  I did this because regular email works fine from this location but the XEP didn't.
 
An unauthenticated conversation looks like this:
>>> (from server to xep)
<<< (from xep to server)


>>> 220 mail.domain.com ESMTP
<<< EHLO domain.com{13}{10}
>>> 250-mail.domain.com
>>> 250-PIPELINING
>>> 250-8BITMIME
>>> 250-AUTH LOGIN PLAIN CRAM-MD5
>>> 250 STARTTLS
<<< MAIL FROM: <[email protected]>{13}{10}
>>> 250 ok
<<< RCPT TO: <[email protected]>{13}{10}
>>> 250 ok
<<< DATA{13}{10}
>>> 354 go ahead
<<< MIME-Version: 1.0{13}{10}
    To: [email protected]{13}{10}
    From: [email protected]{13}{10}
    Cc: {13}{10}
    Subject: Email Alert{13}{10}
    X-Mailer: Allegro Software RomMailer /4.01{13}{10}
    Content-Type: text/plain; charset=iso-8859-1{13}{10}
    Content-Transfer-Encoding: 7bit{13}{10}
    {13}{10}
<<< test{13}{10}.{13}{10}
>>> 250 ok
<<< QUIT{13}{10}
>>> 221 mail.domain.com

Nothing special.
 
An authenticated conversation looks like this


>>> 220 mail.domain.com ESMTP
<<< EHLO domain.com{13}{10}
>>> 250-mail.domain.com
>>> 250-PIPELINING
>>> 250-8BITMIME
>>> 250-AUTH LOGIN PLAIN CRAM-MD5
>>> 250 STARTTLS
<<< AUTH CRAM-MD5{13}{10}
>>> 334 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<<< xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx{13}{10}
>>> 235 Authentication successful.
<<< MAIL FROM: <[email protected]>{13}{10}
>>> 250 ok
<<< RCPT TO: <[email protected]>{13}{10}
>>> 250 ok
<<< DATA{13}{10}
>>> 354 go ahead
<<< MIME-Version: 1.0{13}{10}
    To: [email protected]{13}{10}
    From: [email protected]{13}{10}
    Cc: {13}{10}
    Subject: Email Alert{13}{10}
    X-Mailer: Allegro Software RomMailer /4.01{13}{10}
    Content-Type: text/plain; charset=iso-8859-1{13}{10}
    Content-Transfer-Encoding: 7bit{13}{10}
    {13}{10}
<<< test{13}{10}.{13}{10}
>>> 250 ok
<<< QUIT{13}{10}
>>> 221 mail.domain.com

Again, nothing special.  The ELK uses challenge-response to authenticate.
 
So why doesn't it work when I connect to my real server?


telnet mail.mydomain.com 25
220 rblsmtpd.local
EHLO domain.com
451 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?###.###.###.###
And that's what the XEP isn't telling you. 
 
This particular error is on my end.  I need to (figure out how to) reconfigure qmail to allow the IP address range that the XEP is on.
 
In the meantime, I was able to relay though my ISP's (Charter) server:
XEP configuration:
   server: smtp.charter.net  port: 25
   from: [email protected]
   username and password blank (not needed since I'm inside the Charter network)
 
Suggestions for ELK
1) Better error handling for connections - rebooting the XEP just isn't acceptable
2) View conversation between the XEP and the email server.  It helps to know what the problem is in order to solve it.
3) The generic subject of "Email Alert" doesn't cut it.  A separate subject for each message would be more useful.
 
 
 

Many of us will agree, the M1XEP could benefit from a significant upgrade.  Hopefully ELK is keep tracking of all our suggestions

I hate seeing others struggle with this, knowing that it literally took me ~5 minutes to setup mine and get it working, I had not worked with the XEP before, and I get messages from my almost Elk everyday. But, since I didn't have any problems, I really don't know much about troubleshooting the XEP.
 
All I can say is that I know there are reports (including in their videos regarding setup of the XEP) that it does have issues with a few of the free email providers. I think this alone may be why my setup was relatively easy - I'm using a mail server of my own...

I'm wondering if it would be worth setting up a CocoonTech SMTP relay service, for registered & active members only.  I would have to lock it down by IP address tho, which might make this less useful.

I've managed to get my XEP to work in two homes, but is Elk EVER going to update this thing? They may as well send an offer for AOL dial up service with it... This is a wonderful security system that could use some fresh blood in the product line to remain relevant. Lack of innovation is not good in most companies, especially those built on technology.

I'm sure it's something they are working on for the next gen platform (assuming they are working on this), instead of trying to fix a difficult problem.

It does not help that they have incorrect instructions on their website...

Has anyone heard or read of a next-gen Elk in development?

I had a similar setup issue. I'm a happy Gmail user but no SSL lovin' for the XEP faithful. I ended up sending the ELK emails to my ISP's free email account and setting it to forward all inbound mail to my Gmail acct. Been working fine for over a year so ill leave it for now..

I use my ISY-99i to make up for the Elk email shortcomings. No issues with gmail and much better email capabilities / possibilities.

Otherwise if any of you guys has a step by step to configure the email that would be great....because I can't figure it out.