On Mon, 19 Jul 1999, Jean-Michel TEXIER wrote:
> I've some communication problem between sendmail and IMailServer.
Yeah, me too. In fact I asked for this to be resolved in the next release,
and was told this was being favorably considered by the product manager.
I now appeal to you, mail admins to make this a Product Improvement
Request.
> Some customer use sendmail as SMTP server to send e-mail to our
> accounts. Each time the destination user is unknown the sendmail
> process send a "Bad mail" message to our IMailServer but with a "Null
> Sender" instead of the original sender (the customer e-mail address)
> so as "Refuse NULL Sender" is checked, the bad mail never reach our
> domain... Do you know how to proceed in order to fix this ? (maybe
> some setting up on sendmail ?)
Please allow me to suggest you can resolve this via a setting in Imail.
Please see my comments below.
> Thanks.
> Jean-Michel.
>
> ----- Transcript of session follows -----
> ... while talking to mail.vanuatu.com.vu.:
> >>> MAIL From: SIZE=1386
> <<< 501 bogus mail from
>
> ========================================================
> CORTEX Engineering
> "The Mind Of Computer Engineering"
>
> [EMAIL PROTECTED]
> www.cortex.nc
> ========================================================
Please condider the following with an open mind, and an eye for the
technical issues, together with an understanding that we all need to
cooperate to make the internet work, now and in the future.
Imail servers can be configured to refuse 'MAIL From: <>'
The correct name for that field is the Envelope Return Address.
The "Host Requirements" standard, RFC 1123, requires that ALL internet
connected mail servers MUST accept the ENVELOPE 'MAIL From: <>'.
You do not have to accept the HEADER 'From: <>', as that would indeed
be bogus.
A blank Envelope Return Address is perfectly legal and, in fact, all
bounces (and other Delivery Status Notifications) have blank envelope
return addresses.
Note that in the example you mention, sendmail correctly generated:
MAIL From: <>
From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
These two headers have entirely different purposes. The 'MAIL From: <>'
is intended to prevent an infinite loop of Delivery Status Notifications
between mail servers.
The 'From: ' field is designed to be shown in the mail client program.
The mail client (outlook, eudora, etc) does not normally show or use the
'MAIL From: ' Envelope Return Address.
See RFC 1123, section 5.2.9 for details.
These messages are generated by sendmail in response to a 'confirm
delivery' status request your user ASKED for, or a nondelivery status
message destined for your customer.
In either case, you are denying information your customer should be getting.
The sendmail admin has very little need to know that your customer sent to
an adddress that does not work. Your customer has a need to know if his
mail was not delivered.
Your customer should be getting the error messages, so
1. He can know that the recipient did not receive the mail he sent.
2. If there was a minor typo in the recipient address, and the mail
was important, your customer can fix the typo and send it again,
in a timely manner.
If the mail was important, your customer NEEDS to know it was not
delivered.
Gentlemen, please - in the process of blocking spam, let us not break the
fundamental mechanisms built into e-mail.
your good net neighbor,
-bryan
***********
Appendix -
MAIL FROM:<> must be accepted, see the following standards:
http://www.faqs.org/rfcs/rfc821.html section 3.6 says:
If a server-SMTP has accepted the task of relaying the mail and
later finds that the forward-path is incorrect or that the mail
cannot be delivered for whatever reason, then it must construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the
reverse-path).
This notification message must be from the server-SMTP at this
host. Of course, server-SMTPs should not send notification
messages about problems with notification messages. One way to
prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a
message is relayed it is permissible to leave the reverse-path
null. A MAIL command with a null reverse-path appears as follows:
MAIL FROM:<>
http://www.faqs.org/rfcs/rfc1123.html section 5.2.9 says:
5.2.9 Command Syntax: RFC-821 Section 4.1.2
The syntax shown in RFC-821 for the MAIL FROM: command omits
the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page
15). An empty reverse path MUST be supported.
http://www.faqs.org/rfcs/rfc2505.html section 2 says:
Here we first give a brief list of recommendations, followed by a
more thorough discussion of each of them. We will also give
recommendations on things NOT to do, things that may seem natural in
the spam fight (and might even work so far) but that might wreak
havoc on Internet mail and thus may cause more damage than good.
[...]
2.6a) MUST NOT refuse "MAIL From: <>".
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
