none
Send Mail task did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v4

    Dotaz

  • I've got a Send Mail Task that usually works fine, using an SMTP connection manager with default properties (UseWindowsAuthentication and EnableSsl both false).  It works on my test and stage server, but not my production server: in that case, the SMTP server reports "host.domain [IP address] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v4".

    The strange thing is that I have other packages that use an identical SMTP connection manager in Send Mail tasks, and they work fine on the production server.

    Does SQL Server Database Mail have anything to do with the SSIS Send Mail task?  I wouldn't think so, since there's no way to specify a Database Mail Profile in either the Send Mail task or the SMTP connection manager.

    In the case where it does not work, the package is being invoked via dtexec from a SQL Agent job.  Does that have anything to do with the SSIS Send Mail task?
    Sr. Software Engineer, Data Accumulation Systems, IHS
    20. srpna 2009 19:07

Všechny reakce

  • Database mail shouldn't have anything to do with SSIS package Send Mail task.

    Is it 2005 or 2008? Is it x64 bit?

    The most common problem when using a job is the security context. Are you using a proxy account, or just running the job under the context of the SQL Agent service account? Are the working packages using the same settings?

    If you run the package from the command prompt using RunAs to simulate the security context of SQL Agent / the proxy account, does it work?

    Start > run > cmd
    RunAs /user:domain\user cmd.exe
    type in password for the user

    Then in the new cmd windows run your package DTExec.exe /file:c:\mypackage.dtsx etc...

    Thanks, Jason

    Didn't get enough help here? Submit a case with the Microsoft Customer Support team for deeper investigation - http://support.microsoft.com/select/default.aspx?target=assistance
    21. srpna 2009 3:28
  • [Yao-Jie Tang: Jason H's reply is helpful but it is not the answer and since you didn't ask the question you are not qualified to mark it as such.]

    Jason H writes:

    Is it 2005 or 2008? Is it x64 bit?

    This is SQL Server 2005, 64 bit.

    The most common problem when using a job is the security context. Are you using a proxy account, or just running the job under the context of the SQL Agent service account?

    Yes, the SQL Agent job is run as a proxy account.  The proxy is active to the Operating System (CmdExec) subsystem because the SSIS package is invoked via dtexec.  The proxy is associated with a credential, but I don't know what that means -- this was set up by a remote contractor.

    Are the working packages using the same settings?

    I'll ask our DBAs to verify that (I don't have access to the production server).

    If you run the package from the command prompt using RunAs to simulate the security context of SQL Agent / the proxy account, does it work?

    Start > run > cmd
    RunAs /user:domain\user cmd.exe
    type in password for the user

    Then in the new cmd windows run your package DTExec.exe /file:c:\mypackage.dtsx etc...

    I'll ask our DBAs to try that.

    Thanks for the suggestions!
    Sr. Software Engineer, Data Accumulation Systems, IHS
    24. srpna 2009 21:07
  • [Yao-Jie Tang: Jason H's reply is helpful but it is not the answer and since you didn't ask the question you are not qualified to mark it as such.]

    Hi Kevin,
    you have power to unmark this answer. this option is available for you.

    Thanks-
    Let us TRY this | Don’t forget to mark the post(s) that answered your question
    25. srpna 2009 1:50