I am using Windows 2003 Server and I'm wondering if the SMTP mail service that is part of IIS (v6.0) has a character limit on the subject line?
It shouldn't; not according to RFC 2822
It's not SMTP or IIS, but the underlying message that determines the subject. SMTP is the application layer transport protocol, which abstracts the sending of the e-mail message. IIS does funky things, but shouldn't break standards.
Related
My company uses Microsoft exchange mail server How could I configure incoming server with pop in OpenERP, which is hosted by sherweb2010 I know how to do for gmail and works fine, Is there any difference?
No There is not any Difference Between gmail and shareweb2010
if you configure the shareweb2010 then you can use the outlook setting in openerp
We have a IIS 6.0 server on AWS EC2 that is receiving emails and forwarding onto another IIS box, we are inadvertently sending NDR emails via the SMTP service to the forged From: header with the spam attached.
A few quick questions regarding IIS 6.0 SMTP
From reading we don't see a was to stop NDRs (this is by design to meet RFC requirements)
As we accept all emails sent to our address and process off line on a seperate machine can someone advise why NDR's are been delivered in the first place? Is there some other loophole they are using to force the SMTP server to generate Delayed and Non Delivery Reports?
Also can anyone recommend software that can stop this type of attack. e.g. Toriss, ORF from Vamsoft
You have to use SPF on the receiving machine so it does not accept mails with forged reverse-paths. There is no way to really fix the issue later in the mail server chain. (Note that the SMTP reverse path is not necessarily the same as the address in the From header, for example they always differ in list mails. If IIS does send bounce mails to the From address instead of the reverse-path then it is horribly broken.) If IIS does not know SPF, then you have to use a different mail server or an SMTP proxy.
I have a windows server running an application which sends mail via PHP. Some of the people who should be recieving the emails are complaining they are not getting them. I think they are using Comcast or AOL. What can I do to my SMTP settings and/or DNS to allow these to go through?
Investigate SPF (Sender Protection Framework) to increase the authenticity of your emails.
I have a very simple .net application for testing SMTP on .net. But i am receiving this weird error.
"System.Net.Mail.SmtpException: Failure sending mail. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it"
SMTP server is remote and doesn't need any kind of authentication so i don't need credentials. But i can send mails from this computer with outlook using same smtp server and same smtp settings without any problem.
Any ideas? It will be appreciated so much.
Imports System.Net.Mail
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim smtp As New SmtpClient
smtp.Host = "10.241.128.220"
smtp.Port = 25
smtp.Send("nuri-fatih.guler#rzb.ro", "nuri-fatih.guler#rzb.ro", "test", "test")
End Sub
Ensure that the machine you are sending the emails from has permissions to use this mail server as a relay. This is less a programming issue, and more a server issue, so it might be better answered at Serverfault.
Here's a good place to start, though: http://support.microsoft.com/kb/895853
Edit - added.
I found the list below at a different site.
These are the 4 most likely causes for the issue.
there isn't any service running at the IP:Port you specified.
there is a firewall in the way (at the client or server)
there is a virus scanner in the way (at the client or server)
Your mail server doesn't like the originating IP, so it is dropping the connection.
My answer above was to address point #4, since most mail servers allow you to block pass-through functionality and open it up to specific IP addresses.
So the SMTP server has to be configured to allow the IP address of the machine you're using to use it as a pass-through SMTP server, which is what you're doing when using the System.Net.Mail namespace and specifying a mail server other than local host.
Typically, when I have experienced issue #4, I could send using Outlook. In this situation, the following has to be true:
The mail server must be using Exchange
Outlook is connecting using MAPI (the default when connecting to an Exchange server).
In this case, Exchange works, because IMAP is not being blocked, BUT System.Net.Mail uses SMTP, and SMTP may be blocked when MAPI is not.
I discovered the problem. It was because of McAfee Antivirus. It blocked 25 port. I disabled it and problem has been solved. Thanks to everybody. Especially David.
Outlook might not be using SMTP to send emails
Are you sure Outlook is not connecting using SSL?
internally, our organization limits what servers and applications can send emails. I would like to be able to have scripts that could be run on any server send an email when done. Is it possible to install IIS SMTP on a single server and have that relay all mail the servers send to our standard relay servers? All the advice I see on the internet talks about configuring relays for outbound connectivity, but this would be for internal use only. the flow would be something like this, I believe
[any server] --> My SMTP relay --> corporate SMTP relay --> Internal Mail system
Is this doable? if so, any links on how to configure? I have nearly zero SMTP knowledge.
Doable, you should search for "SMARTHOST SMTP" in google. If your mail server limits relaying to specific HOSTS/IP address, you'll still need to add the new server to the relay list. Setup will be a little different depending on you mail server/version (Exchange, IIS SMTP).
SMART HOST for Exchange:
http://www.dnsexit.com/support/mailrelay/exchange/setup.htm
I have a similar setup to what you have described. You might want want to check if your SMTP server allows relaying for authenticated users, since this might allow you current script to send emails using a domain/email user account.