When an email is sent, it should contain no “Received” header fields. Each time the email is processed by a mail server along the delivery route, a new Received header field is prepended to the email. The very first Received header is added by the SMTP server that the SMTP client (such as your app or a program such as Outlook) connects to to send email.
A typical scenario is that an email will contain two Received headers when delivery is complete. The 1st is the Receive header added by your SMTP server. This may often be something like “localhost” and may show an internal IP address, such as “192.168.1.###”. Your SMTP server then relays the email to its destination, and the mail server at the destination (at the receiver) then adds its Received header.
The Received header has a syntax such as this:
Received: from ? by ? via ? with ? id ? for ? ; date-time
Some mail servers may not include all the parts, and spammers often fake Received headers.
I have downloaded the Chilkat Email component for POP3/SMTP. When I tried to send email by attaching a file of size of 2 MB, the email is not been sent. Could you please let me know how I can send large size attachments using the Chilkat component?
There is no limitation in the Chilkat Email component. It can send emails with attachments of any size. The limitation is most likely in the SMTP server, or in the receiving mail server (not accepting emails larger than a certain size). I would recommend examining the contents of the mailman.LastErrorText property after calling SendEmail (or after calling whichever method is used to send the email). If everything looks OK and the SendEmail was successful, then check your SMTP server logs. If all seems OK there, then it may be a limitation in the destination (recipient) mail server, or perhaps a size limitation set for the recipients email account.
When an email is sent with BCC recipients, the BCC email addresses are not listed in the header. The “To” recipients are listed in the “To” header field, and the “CC” recipients are listed in the “CC” header field, but the BCC recipients are intentionally left out. This is what makes it a “blind” carbon copy — the recipients are unable to see the BCC recipients. (It is by design.) Otherwise the BCC recipients would be equivalent to “CC” recipients. To understand how BCC recipients receive an email, I recommend reading this blog post: SMTP Protocol in a Nutshell. The BCC recipients are passed to the SMTP server in “RCPT TO” commands.
To solve this problem, set the Chilkat.Mailman’s HeloHostname property equal to the fully-qualified hostname of the computer where your application is running.
I started using MailMan.VerifyRecipients to periodically check bad email addresses and within one week of using the method the server was blacklisted.
Is this something you have heard of? or just coincidence?
I haven’t heard of this before — thanks for letting me know.
I suspect the reason is that VerifyRecipients works by connecting to an SMTP server and issuing “RCPT TO” commands for the purpose of getting the server’s success/failure response, but it stops short of actually sending an email. This must be a tactic used by spammers to determine good/bad email addresses — and I hadn’t thought of that. I’m going to add a note to the reference documentation to warn programmers to avoid this method. You can instead call mailman.GetBadEmailAddresses() to get the failed email addresses (if any) after SendEmail is called. The mailman.AllOrNone property controls whether SendEmail will return a failed status if some of the email addresses were indicated “bad” by the SMTP server.
Here is a link to a page with related information about validating email addresses:
Can one test if a specific email address is OK before sending?
The answer to this question is located here:
Is it possible to check if an email is delivered properly?
The Chilkat MailMan is an SMTP client. It connects to an SMTP server to initiate the delivery of email. Typically you would connect to your company’s or ISP’s SMTP server. If the email is to be sent elsewhere, the SMTP server relays the email to the remote SMTP server (or to some other intermediate mail server). The SMTP client can only report back whether the initial “handoff” is successful. There are cases where the initial “handoff” fails, and these would result in a failed status return by the mail-sending method call.
Here is a collection of blog posts related to this topic:
Requesting Read Receipts and Delivery Receipts
Diagnosing SMTP Failures
RFC 3461 SMTP DSN Extension
SMTP Protocol in a Nutshell
Is it Possible to Connect Directly to the Recipient’s SMTP Server?
Checking TCP Connectivity
Email Bounce Processing Examples
* When sending email, you may set the email address’s BounceAddress property to specify a mailbox where bounces (i.e. DSN’s) are to be sent. You may write a separate application to read that mailbox using Chilkat Email (or Chilkat IMAP) in conjunction with the Chilkat Bounce component to categorize emails as bounces or not bounces, get the type of bounce, and the original sender (if possible).
ASP: Bounced Email Handling
C#: Bounced Email Handling
C++: Bounced Email Handling
MFC: Bounced Email Handling
C: Bounced Email Handling
Delphi: Bounced Email Handling
Visual FoxPro: Bounced Email Handling
Java: Bounced Email Handling
Perl: Bounced Email Handling
PHP: Bounced Email Handling
Python: Bounced Email Handling
Ruby: Bounced Email Handling
VB.NET: Bounced Email Handling
Visual Basic: Bounced Email Handling
VBScript: Bounced Email Handling