Implements a SMTP Relay agent.
TIdSMTPRelay = class(TIdSMTPBase);
TIdSMTPRelay is a TIdSMTPBase descendant that implements a SMTP Relay agent.
An important feature of SMTP is its capability to transport mail across networks, usually referred to as "SMTP mail relaying". Using the SMTP protocol, a relay can transfer mail to another process on the same network or to some other network. With SMTP relay, a mail message may pass through a number of intermediate relay or gateway hosts on its path from sender to ultimate recipient. The Mail eXchanger mechanisms of the domain name system (DNS) are used to identify the appropriate next-hop destination for a message being transported. A "relay" SMTP system (usually referred to just as a "relay") receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery.
When you attempt to send SMTP mail or use SMTP Relay features, you may receive an error message that your e-mail cannot be sent due to SMTP relay blocking.
The exact error message may vary, depending on your Internet Service Provider (ISP); however, it will be similar to the following error message:
The message could not be sent because one of the recipients was rejected by the server. The rejected e-mail address was '<email@example.com>' Subject: '<Test>' Account: '<Test>' Server: '<smtp.somedomain.com>' Protocol: SMTP Server Response: '550 <firstname.lastname@example.org>... Relaying Denied' Port: 25 Secure (SSL): No Server Error: 550
This problem can occur when the ISP uses an Internet gateway and you are attempting to send e-mail through an Internet Service Provider's SMTP gateway. The condition may also occur when attempt to send e-mail through another Internet Service Provider's SMTP gateway. Another cause is when the reply address in the mail account properties is different than that of your Internet Service Provider.
This problem affects all messaging clients, regardless of manufacturer.
Customers should contact their ISP for assistance since this problem is not caused by the e-mail client. From a messaging client standpoint, there are no solutions for customers who have ISP's that block all SMTP Relay traffic.
Most of the new SMTP e-mail gateway software can allow relaying for specific IP addresses. This is how cable modem and ADSL users will be able to continue to use their same ISP. The cable modem or ADSL provider must provide the customer a static IP address, in turn, the customer's e-mail ISP will allow relaying for that specific IP address. Banks of IP addresses can also be allowed which may provide a workaround for some corporate customers who access ISP's through their corporate LAN.
If the error is random, it is possible that your SMTP server is checking whether the domain for the recipient name actually exists before sending. If the recipient's mail server is temporarily down or unavailable for another reason, such as high network volume, your SMTP server cannot verify the address and may reject the relay. In this case, no action is required. The message will be sent when the receiving server is again available.
This problem may become more common as ISP's begin to take action against SPAM e-mail. SPAM is flooding the Internet with many copies of the same message in an attempt to send the message to people who would not otherwise choose to receive it. Most SPAM uses an automated system to send commercial advertising, or mass marketing e-mail messages. SPAM costs the sender very little to send; most of the costs are paid for by the recipient or the e-mail providers.
Some ISP's are fighting SPAM by requiring each user to be dialed directly into their system in order to send e-mail through their SMTP gateway. This is an easy way to control SPAM but may affect some users who tunnel into their e-mail account from another ISP.
TIdSMTPRelay connects directly with the recipient's SMTP server and delivers the message. It does not use a relay SMTP server to deliver the message.
TIdSMTPRelay introduces the StatusList property containing the status of each recipients' address after the Send method is called and the OnDirectSMTPStatus event handler to keep track of the status as the sending is in progress.
D.3 Relayed Mail Scenario
Step 1 -- Source Host to Relay Host S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM:<JQP@bar.com> S: 250 OK C: RCPT TO:<@foo.com:Jones@XYZ.COM> S: 250 OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Date: Thu, 21 May 1998 05:33:29 -0700 C: From: John Q. Public <JQP@bar.com> C: Subject: The Next Meeting of the Board C: To: Jones@xyz.com C: C: Bill: C: The next meeting of the board of directors will be C: on Tuesday. C: John. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel
Step 2 -- Relay Host to Destination Host S: 220 xyz.com Simple Mail Transfer Service Ready C: EHLO foo.com S: 250 xyz.com is on the air C: MAIL FROM:<@foo.com:JQP@bar.com> S: 250 OK C: RCPT TO:<Jones@XYZ.COM> S: 250 OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Received: from bar.com by foo.com ; Thu, 21 May 1998 C: 05:33:29 -0700 C: Date: Thu, 21 May 1998 05:33:22 -0700 C: From: John Q. Public <JQP@bar.com> C: Subject: The Next Meeting of the Board C: To: Jones@xyz.com C: C: Bill: C: The next meeting of the board of directors will be C: on Tuesday. C: John. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel
D.4 Verifying and Sending Scenario S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250-VRFY S: 250 HELP C: VRFY Crispin S: 250 Mark Crispin <Admin.MRC@foo.com> C: SEND FROM:<EAK@bar.com> S: 250 OK C: RCPT TO:<Admin.MRC@foo.com> S: 250 OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Blah blah blah... C: ...etc. etc. etc. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel
Discuss implementation details.
Discuss TLS and SSL.
Discuss authentication methods and requirements.
Copyright © 1993-2006, Chad Z. Hower (aka Kudzu) and the Indy Pit Crew. All rights reserved.
Post feedback to the Indy Docs Newsgroup.