mail about unknown user gets lost

Hello,
I would like to know, which server in the following scenario, where an
error message gets lost, is not conform to the standards:

1.) user1@domain1 sends email to user2@domain2
2.) smtp-server.domain1 sends email successfully to
smtp-server.domain2 (eSafe)
3.) smtp-server.domain2 tries to send email to internal smtp-server of
domain2 (Lotus), but Lotus responds with error "unknown user"
4.) smtp-server.domain2 (eSafe) sends back an error-message to
user1@domain1 but with empty "From:" address
5.) smtp-server.domain1 (Postfix) does not accept such message with empty
sender
6.) user1@domain1 will never know, that user2 does not exist

So here my questions:
- Is it correct, that smtp-server.domain2 uses empty sender-address?
- Is it correct, that smtp-server.domain1 refuses such message?

If you have an answer to theses questions, where is it written down, how to
do it right?

Thanks in advance for any hints!
Greetings, Peter

--
email: pmrb at free.fr
http://pmrb.free.fr/contact/

Re: mail about unknown user gets lost

"Peter Münster" wrote in message
news:Pine.LNX.4.58.0603151440200.29186@gaston.deltadore.bzh

> 4.) smtp-server.domain2 (eSafe) sends back an error-message to
> user1@domain1 but with empty "From:" address
> 5.) smtp-server.domain1 (Postfix) does not accept such message with
> empty sender
>
> So here my questions:
> - Is it correct, that smtp-server.domain2 uses empty sender-address?
> - Is it correct, that smtp-server.domain1 refuses such message?

Read what you yourself wrote.

Re: mail about unknown user gets lost

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-2425-1142465488-0002
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg

Peter Münster writes:

> Hello,
> I would like to know, which server in the following scenario, where an
> error message gets lost, is not conform to the standards:
>=20
> 1.) user1@domain1 sends email to user2@domain2
> 2.) smtp-server.domain1 sends email successfully to
> smtp-server.domain2 (eSafe)
> 3.) smtp-server.domain2 tries to send email to internal smtp-server of
> domain2 (Lotus), but Lotus responds with error "unknown user"
> 4.) smtp-server.domain2 (eSafe) sends back an error-message to
> user1@domain1 but with empty "From:" address

Highly unlikely.

You are probably confusing the contents of the From: header with the mess=
age=20
envelope return address.

Bounces rarely have an empty From: header, but bounces always have an emp=
ty=20
envelope return address (except for rare cases of broken/misconfigured ma=
il=20
servers).

> 5.) smtp-server.domain1 (Postfix) does not accept such message with emp=
ty
> sender
> 6.) user1@domain1 will never know, that user2 does not exist
>=20
> So here my questions:
> - Is it correct, that smtp-server.domain2 uses empty sender-address?

Bounces must have an empty envelope return address.

> - Is it correct, that smtp-server.domain1 refuses such message?

Any mail server may reject any message for any reason. Having said that:

Envelope return addresses must be empty for bounces. Mail servers that=20
unilaterally refuse to accept mail with empty return addreses should be=20
blacklisted, as they do not meet the technical definition of a "mail=20
server". However, I do not believe that there's anything wrong with=20
rejecting a message that happens to carry an empty return address, if it=20
gets rejected for other reasons. Just because the message carries an emp=
ty=20
return address does not mean that the recipient server must accept it, an=
d=20
normal site policies still apply. Of course, if a server rejects a messa=
ge=20
it's not always possible to determine why it did so; these are just gener=
al=20
guidelines; but it nearly all cases a fairly educated guess can usually b=
e=20
made.

However, your scenario also demonstrates a problem with "domain2". Their=20
mail system is misdesigned, and broken. It is vulnerable to a well-known=20
general security hole -- backscatter generation/bandwidth amplification -=
-=20
which is generally considered to be grounds for immediately blacklisting=20
"domain2"'s mail server, without further notice.

Many popular blacklists can, and will, blacklist domain2, when backscatte=
r=20
from domain2 comes to their attention. It's only a matter of time. I,=20
personally, blacklist almost two thousand similarly misconfigured=20
organizations whose mail servers are spewing backscatter, which saves me=20
from having to deal with thousands of junk garbage mails every week.

> If you have an answer to theses questions, where is it written down, ho=
w to
> do it right?

Actually, surprisingly few of the above is formally written down. These=20
things have evolved over the course of a number of decades of practical=20
experience. The above, I believe, represents the general consensus that =
has=20
evolved on the Internet, for quite some time. And things still continue =
to=20
change, but very slowly.

>=20
> Thanks in advance for any hints!
> Greetings, Peter
>=20
> --=20
> email: pmrb at free.fr
> http://pmrb.free.fr/contact/

--=_mimegpg-commodore.email-scan.com-2425-1142465488-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEGKPQx9p3GYHlUOIRAn9gAJ4gD1e91hL8H2FHupHOqoRNoEKRpgCe OPwC
sPyDIa1/oNWf/dVzHUOXiPk=
=uHkO
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-2425-1142465488-0002--

Re: mail about unknown user gets lost

Peter Münster wrote:

> Hello,
> I would like to know, which server in the following scenario, where an
> error message gets lost, is not conform to the standards:
>
> 1.) user1@domain1 sends email to user2@domain2
> 2.) smtp-server.domain1 sends email successfully to
> smtp-server.domain2 (eSafe)
> 3.) smtp-server.domain2 tries to send email to internal smtp-server of
> domain2 (Lotus), but Lotus responds with error "unknown user"
> 4.) smtp-server.domain2 (eSafe) sends back an error-message to
> user1@domain1 but with empty "From:" address
> 5.) smtp-server.domain1 (Postfix) does not accept such message with empty
> sender
> 6.) user1@domain1 will never know, that user2 does not exist
>
> So here my questions:
> - Is it correct, that smtp-server.domain2 uses empty sender-address?
> - Is it correct, that smtp-server.domain1 refuses such message?
>
> If you have an answer to theses questions, where is it written down, how to
> do it right?
>
> Thanks in advance for any hints!
> Greetings, Peter
>

Peter,

Sam answered your question in great detail.
The short answer.
smtp-server on domain2 send a failure notice with the From line
reflecting something of the following:
MAILER-DAEMON@smtp-server.domain2
sysadmin@smtp-server.domain2
etc.
which have no actual significance on the email as that item is never
evaluated by the server (outside of filtering mechanism)

During the SMTP session between smtp-server.domain2 and
smtp-server.domain1 where domain2 identifies itself to domain1 by saying
helo smtp-server.domain2.
smtp-server.domain2 is A
smtp=server.domain1 is B.
Once the greating has been accepted by B with a 2xx B. Hello A.
A identifies the sender of the message (Envelope Sender). In case of a
bounce/failure notice the sender is null, empty <> which will look like
mail from: <>
B should respond Sender OK based on the RFC by issueing a 2xx sender ok.
A designates the recipient of the message (envelope recipient) in your
example it is user1@domain1 as follows.
rcpt to: B is supposed to either accept the recipient or reject (2xx to accept,
4xx to indicate that there is a temporary problem and A should try again
later, or 5xx that there is a permanent problem no such user, etc. and A
must not try again.)
in your case however, B says no thank you by issuing a 5xx permanent
error when it sees an empty envelope recipient.

Like Sam said server B is not complying with the RFC as to
acceptable/expected behavior from a mail server.

Administrators of server A will say that the administrators of server B
are off their rocker(nuts).
Administrators of server B will say that the administrators of server A
are off their rocker since they should not accept a message if the
recipient does not exist.

Both have valid points of view. Administrators of server A are in full
compliance with the RFC for SMTP. Their server will either notify the
sending mail server of an error during the SMTP session or will notify
the (envelope sender) should the final delivery to the (envelope recipient).

Administrators of server B want to minimize their bandwidth consumption
so they require all other administrators to configure their mail servers
to check whether the envelope recipient exists on their system and
reject the mailing when the recipient is unknown. Some servers have
this functionality and some do not.

This leaves you where you started, SOL if you have server A.

Person from domain1 will never know that they misstyped the email
address to whom the message was sent unless person from domain2 is
waiting for the email and will notify the user of domain1 that the
message has not arrived.

AK

Re: mail about unknown user gets lost

On Wed, 15 Mar 2006, Sam wrote:

> > 1.) user1@domain1 sends email to user2@domain2
> > 2.) smtp-server.domain1 sends email successfully to
> > smtp-server.domain2 (eSafe)
> > 3.) smtp-server.domain2 tries to send email to internal smtp-server of
> > domain2 (Lotus), but Lotus responds with error "unknown user"
> > 4.) smtp-server.domain2 (eSafe) sends back an error-message to
> > user1@domain1 but with empty "From:" address
>
> Highly unlikely.
>
> You are probably confusing the contents of the From: header with the message
> envelope return address.

Hello Sam,
I'm not sure. I tested with a domain3, that does not refuse messages with
empty "From:" header, so I can get the bounce-message:
Return-Path:
From: <>

So I suppose, that the envelope return address of domain2 was really empty,
so that domain3 adds itself his return address. But is it normal, that the
"From:" line is also empty?

In fact, I'm working at domain2, and often people are trying to send me
email but with wrong spelling of my name and often they don't get any
error-message because they have an smtp-server of type domain1.

> Envelope return addresses must be empty for bounces. Mail servers that
> unilaterally refuse to accept mail with empty return addreses should be
> blacklisted, as they do not meet the technical definition of a "mail
> server". However, I do not believe that there's anything wrong with
> rejecting a message that happens to carry an empty return address, if it
> gets rejected for other reasons. Just because the message carries an empty
> return address does not mean that the recipient server must accept it, and
> normal site policies still apply. Of course, if a server rejects a message
> it's not always possible to determine why it did so; these are just general
> guidelines; but it nearly all cases a fairly educated guess can usually be
> made.

So, perhaps the envelope return addresses is empty, but domain1 rejects the
message because of the empty "From:" address.

> However, your scenario also demonstrates a problem with "domain2". Their
> mail system is misdesigned, and broken. It is vulnerable to a well-known
> general security hole -- backscatter generation/bandwidth amplification --
> which is generally considered to be grounds for immediately blacklisting
> "domain2"'s mail server, without further notice.

Ok, this is something, that I can already transmit to our
smtp-administrator. Thank you!

I think, the last question is: should I tell our smtp-administrator also,
that the "From:" line should not be empty, or are all the servers of type
domain1 misconfigured?

Thanks a lot to you and AK for your explanations!
Cheers, Peter

--
email: pmrb at free.fr
http://pmrb.free.fr/contact/

Re: mail about unknown user gets lost

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-15004-1142510184-0002
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg

Peter Münster writes:

> On Wed, 15 Mar 2006, Sam wrote:
>=20
>> > 1.) user1@domain1 sends email to user2@domain2
>> > 2.) smtp-server.domain1 sends email successfully to
>> > smtp-server.domain2 (eSafe)
>> > 3.) smtp-server.domain2 tries to send email to internal smtp-server =
of
>> > domain2 (Lotus), but Lotus responds with error "unknown user"
>> > 4.) smtp-server.domain2 (eSafe) sends back an error-message to
>> > user1@domain1 but with empty "From:" address
>>=20
>> Highly unlikely.
>>=20
>> You are probably confusing the contents of the From: header with the m=
essage=20
>> envelope return address.
>=20
> Hello Sam,
> I'm not sure. I tested with a domain3, that does not refuse messages wi=
th
> empty "From:" header, so I can get the bounce-message:
> Return-Path:
> From: <>

Anything that generates this nonsense must be scrapped and landfilled.

> So I suppose, that the envelope return address of domain2 was really em=
pty,
> so that domain3 adds itself his return address. But is it normal, that =
the
> "From:" line is also empty?

No. It indicates very ancient, and very broken mail software that should=
n't=20
be allowed on the Internet.
>> However, your scenario also demonstrates a problem with "domain2". Th=
eir=20
>> mail system is misdesigned, and broken. It is vulnerable to a well-kn=
own=20
>> general security hole -- backscatter generation/bandwidth amplificatio=
n --=20
>> which is generally considered to be grounds for immediately blacklisti=
ng=20
>> "domain2"'s mail server, without further notice.
>=20
> Ok, this is something, that I can already transmit to our
> smtp-administrator. Thank you!
>=20
> I think, the last question is: should I tell our smtp-administrator als=
o,
> that the "From:" line should not be empty, or are all the servers of ty=
pe
> domain1 misconfigured?

The From: line should not be empty.

> Thanks a lot to you and AK for your explanations!
> Cheers, Peter
>=20
> --=20
> email: pmrb at free.fr
> http://pmrb.free.fr/contact/

Funny that.

I have free.fr blacklisted for generating abusive backscatter.



--=_mimegpg-commodore.email-scan.com-15004-1142510184-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEGVJox9p3GYHlUOIRAkLOAJ9LZi3ZQdTSIPbFH+J14oC7lxbQ8QCf U/ID
RQD147JNt4MmMnY3KGEZX4Y=
=iklK
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-15004-1142510184-0002--

Re: mail about unknown user gets lost

On Thu, 16 Mar 2006, Sam wrote:

> > email: pmrb at free.fr
> > http://pmrb.free.fr/contact/
>
> Funny that.
>
> I have free.fr blacklisted for generating abusive backscatter.

Indeed funny: free.fr is of type domain1 !
Cheers and thank you for your answers,
Peter

--
email: pmrb at free.fr
http://pmrb.free.fr/contact/

Re: mail about unknown user gets lost

Peter Münster writes:

> Hello,
> I would like to know, which server in the following scenario, where an
> error message gets lost, is not conform to the standards:
>
> 1.) user1@domain1 sends email to user2@domain2
> 2.) smtp-server.domain1 sends email successfully to
> smtp-server.domain2 (eSafe)
> 3.) smtp-server.domain2 tries to send email to internal smtp-server of
> domain2 (Lotus), but Lotus responds with error "unknown user"
> 4.) smtp-server.domain2 (eSafe) sends back an error-message to
> user1@domain1 but with empty "From:" address
> 5.) smtp-server.domain1 (Postfix) does not accept such message with empty
> sender
> 6.) user1@domain1 will never know, that user2 does not exist
>
> So here my questions:
> - Is it correct, that smtp-server.domain2 uses empty sender-address?
> - Is it correct, that smtp-server.domain1 refuses such message?

It is more or less required that mail bounces use command

MAIL FROM:<>

on SMTP.

It is not allowed, that address on From: -header (given on inside
of DATA -command on SMTP) is empty.

/ Kari Hurtta

( STD 10 -- ftp://ftp.rfc-editor.org/in-notes/std/std10.txt

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:<>

)

( RFC 2821 uses more strict wording:

This notification message must be from the SMTP server at the relay
host or the host that first determines that delivery cannot be
accomplished. Of course, SMTP servers MUST NOT send notification
messages about problems transporting 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 transmitted the reverse-path MUST be set to null (see section
4.5.5 for additional discussion). A MAIL command with a null
reverse-path appears as follows:

MAIL FROM:<>

)

STD 10 includes RFC 821, RFC 2821 obsoletes RFC 821 but it is not standard.

Re: mail about unknown user gets lost

Peter Münster writes:

> Hello,
> I would like to know, which server in the following scenario, where an
> error message gets lost, is not conform to the standards:
>
> 1.) user1@domain1 sends email to user2@domain2
> 2.) smtp-server.domain1 sends email successfully to
> smtp-server.domain2 (eSafe)
> 3.) smtp-server.domain2 tries to send email to internal smtp-server of
> domain2 (Lotus), but Lotus responds with error "unknown user"
> 4.) smtp-server.domain2 (eSafe) sends back an error-message to
> user1@domain1 but with empty "From:" address
> 5.) smtp-server.domain1 (Postfix) does not accept such message with empty
> sender
> 6.) user1@domain1 will never know, that user2 does not exist
>
> So here my questions:
> - Is it correct, that smtp-server.domain2 uses empty sender-address?
> - Is it correct, that smtp-server.domain1 refuses such message?
>
> If you have an answer to theses questions, where is it written down, how to
> do it right?

It is required that mail bounces use command
MAIL FROM:<>
on SMTP.

( RFC 821 -- ie STD 10 do not require that, but there is other standards. )

/ Kari Hurtta

( STD 3 - ftp://ftp.rfc-editor.org/in-notes/std/std3.txt

If there is a delivery failure after acceptance of a message,
the receiver-SMTP MUST formulate and mail a notification
message. This notification MUST be sent using a null ("<>")
reverse path in the envelope; see Section 3.6 of RFC-821. The
recipient of this notification SHOULD be the address from the
envelope return path (or the Return-Path: line). However, if
this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. If the address is an explicit source route, it
SHOULD be stripped down to its final hop.

)

Re: mail about unknown user gets lost

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-22021-1142554193-0003
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg

Peter Münster writes:

> On Thu, 16 Mar 2006, Sam wrote:
>=20
>> > email: pmrb at free.fr
>> > http://pmrb.free.fr/contact/
>>=20
>> Funny that.
>>=20
>> I have free.fr blacklisted for generating abusive backscatter.
>=20
> Indeed funny: free.fr is of type domain1 !

No, that's not funny. It's precisely why five free.fr outbound mail serv=
ers=20
have been blacklisted, after flinging crap at my mailboxes, for precisely=20
the reasons I gave above.

It _will_ be funny when some popular antispam blacklist lists=20
212.27.42.0/24, for generating abusive backscatter. That's when the _rea=
l_=20
laughs will be heard on stage.

It's only a matter of time.



--=_mimegpg-commodore.email-scan.com-22021-1142554193-0003
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEGf5Rx9p3GYHlUOIRAudSAJ0cnAQdCdFvhQ3W/Mub077VKvQakACf SsPl
FqC/bBPqfGi0ORrWYJ77T+w=
=hRhb
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-22021-1142554193-0003--

Re: mail about unknown user gets lost

On Thu, 16 Mar 2006, Sam wrote:

> >> Funny that.
> >>
> >> I have free.fr blacklisted for generating abusive backscatter.
> >
> > Indeed funny: free.fr is of type domain1 !
>
> No, that's not funny. It's precisely why five free.fr outbound mail servers
> have been blacklisted, after flinging crap at my mailboxes, for precisely
> the reasons I gave above.

Ok, it's not funny, if free.fr is generating abusive backscatter, but it's
notable, that at the same time, free.fr filters empty "From:" lines, which
is probably not a bad thing (in fact: I don't know...).

> It _will_ be funny when some popular antispam blacklist lists
> 212.27.42.0/24, for generating abusive backscatter. That's when the _real_
> laughs will be heard on stage.
>
> It's only a matter of time.

Then, I'll have to change my provider, not funny for me, but should be
doable.

Cheers, Peter

--
email: pmrb at free.fr
http://pmrb.free.fr/contact/