Hi.

Just sent an email

To: Test CRCA Group <test@crca.org.au>
CC: 'Nigel Cunningham' <ncunningham@crca.org.au>

The current logic causes the cc to be used instead of the to address as the group name, resulting in

An error occurred while processing your submission:
      
       Could not locate group named ncunningham
  
  Please correct this error and try again, or contact the system administrator.  Thank you.

This seems to be a thorny one to me. The user may send one message to multiple lists, or bcc a list. Do we perhaps need a data table with message IDs and lists to which delivery has been already done?

Comments

tobias’s picture

Hi Nigel -

Did the message go through to the group as well? I sent an email to:

To: test4@groups.servername.com
CC: someaddress@gmail.com

and

To: someaddress@gmail.com
CC: test4@groups.servername.com

.. and in both cases I did not get the error you describe.

If your test messages did get delivered to the group, then OGM is behaving just as it should - attempting to deliver the message to you to a group. Your other address is on the group domain after all.

If I were you, I would set up a dedicated domain name just for groups and you won't run into this issue.

Cheers,

Tobias

kyle_mathews’s picture

Status: Active » Closed (duplicate)

What Tobias says makes sense. The problem is the regex there is matching against the server name you've setup. So since both addresses are the same the regex matches both. So like Tobias said, the easiest solution is to just setup your ogm site on either a different domain altogether or a separate subdomain such as lists.domain.com.

The problem of sending the same message to multiple groups is a much trickier one which I haven't worked out a good solution to yet. I started working on that problem at #906952: Modify og_mailinglist_source to store the group-id so I'm going to mark this as a duplicate. Please add any thoughts you have on this topic on the other issue.

nigelcunningham’s picture

Yes, the problem is that both addresses match the regex.

I'll finish off addressing the use of the system command before worrying about anything else.

nigelcunningham’s picture

Title: First email address assumed to be group address » Group address gotten via heuristics instead of parameters from the SMTP agent
Status: Closed (duplicate) » Active

I disagree with requiring the user to have a separate domain for lists. We should be using the email address to which the message was delivered for determining what group the message is being sent to. Using heuristics only increases the chances of simple errors like this, and may even be a source of security issues?

I'm therefore going to reopen and change the description to match what I see as the more basic issue.

kyle_mathews’s picture

I agree actually. The reason we changed to that heuristic before was qmail doesn't have the group name available in a variable.

Check out http://github.com/KyleAMathews/og_mailinglist/commit/440f943abb933a2a437...

It makes passing in the group name optional so MTAs that can, can, and as a backup for MTAs such as qmail, it'll pull out the groupname via the regex.

If that approach makes sense to you, please mark this issue fixed.

nigelcunningham’s picture

I've taken a quick look and it looks good to me. I'll try to actually give it a try later this afternoon and then mark it as fixed. If not today, I should get on to this tomorrow.

Thanks!

kyle_mathews’s picture

K, cool. And I'll revert the Exim setup so that it sends again the group_name as before as I agree that's a more robust solution.

tobias’s picture

I'm not sure I understand what's being discussed here - will this affect my qmail setup?

Cheers,

Tobias

nigelcunningham’s picture

Hi Tobias.

The changes that Kyle has committed will only cause a change if your MTA's script passes a group name in the HTTP POST arguments. Since there are currently no scripts modified to do that, you won't see any change.

HTH!

tobias’s picture

alright - thanks for the confirmation. :)

-T

nigelcunningham’s picture

Status: Active » Fixed

Confirmed fixed in current git.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.