[Vtigercrm-developers] Issues with Scheduled Reports & getReturnPath()

[Prasad]

Alan,

Do accept the apology for pushing in getReturnPath API we failed to cover
exhaustive
case while having the SMTP as localdomain, we indeed targeted only
sub-domain level.

This was an attempt to fix the mail ending up with SPAM
folder<http://trac.vtiger.com/cgi-bin/trac.cgi/ticket/7325>due to
invalid SPF.

Please review the suggested fix and share your feedback:
http://trac.vtiger.com/cgi-bin/trac.cgi/ticket/7325#comment:3

Regards.
Prasad

On Sat, Jun 16, 2012 at 1:19 AM, Joe Bordes <joe at tsolucio.com> wrote:

> I couldn't agree more. In fact we have changed getReturnPath() function
> directly to return a correct email for each client.
>
> I wanted to add one comment to your debugging procedure on the cron. You
> can execute the script directly, no need to wait for the cron, this way
> not only do you have control of when to launch it but you can get errors
> or debug messages on the command line interface screen.
>
> Joe
> TSolucio
>
>
> El 15/06/12 17:03, Alan Lord escribió:
> > I've spent most of the day looking at a problem with a customer not
> > getting Scheduled Reports from vtiger 5.4.0.
> >
> > The new function introduced in 5.4.0 getReturnPath() (bottom of
> > CommonUtils) is a *REALLY* bad idea. (I thought I'd already fixed it
> > once in modules/Emails/mail.php - see
> > https://forums.vtiger.com/viewtopic.php?f=139&t=53251)
> >
> > Our customers frequently use their ISP to relay their emails. Setting
> > the Return Path of the outbound emails from vtiger to
> > "noreply at my-isp.com" triggers some spam prevention and stops emails
> > getting sent by the relay.
> >
> > This getReturnPath() function is being called in three separate email
> > sending code paths (cron/send_mail.php, modules/Emails/mail.php,
> > vtlib/Vtiger/Mailer.php) and is a pig to fix properly. Please make this
> > a priority for 6.0.0. I do not want to have to hack code all over vtiger
> > just so we can send emails!
> >
> > Today has been very frustrating. It is very hard to debug external,
> > authenticated SMTP connections on remote servers. Please can you try not
> > to break this functionality so badly next time...
> >
> > With specific regards to the Scheduled Reports functionality I have two
> > further observations:
> >
> > 1. On sending, there is no "from address" added to the email if the
> > Outgoing Server's from address not configured. (This will also cause
> > some SMTP servers to not send the email). The offending code is in
> > modules/Reports/ScheduledReoports.php. In vtiger_reports, every report
> > has an "owner" id and in my opinion the "from email" should be taken
> > from there initially and if it is empty, use the SMTP from field, if
> > that fails, make something up that is useful like "vtiger at hostname.domain
> ".
> >
> > 2. Scheduled reports are a PITA to test: If you edit a scheduled report
> > and change the time on a daily report. It doesn't update the
> > next_trigger_time row so the report will not run again until whatever
> > the last settings were... This means the easiest way to test is to have
> > a SQL query lined up like:
> >
> > UPDATE `vtiger_scheduled_reports` SET `next_trigger_time` = '2012-06-15
> > 15:43:00' WHERE `vtiger_scheduled_reports`.`reportid` = 24;
> >
> > And then set the scheduler and cron job to run every minute! It would be
> > really helpful to add a tool of some kind to make it easier to test a
> > scheduled anything (report, workflow etc...).
> >
> >
> >
> > Al
> >
> >
> > _______________________________________________
> > http://www.vtiger.com/
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20120616/3a6e8f4b/attachment-0001.html