I appear to be sending hundreds of emails, help!

[Alan]

I have started to receive 'undelivered mail', 'mail not delivered' type
emails by the dozen daily!

I obviously have a bug of some sort, can anyone help me to remove it please?

Kind regards,

Alan

 

[Vanguard]

I have started to receive 'undelivered mail', 'mail not delivered' type
emails by the dozen daily!

I obviously have a bug of some sort, can anyone help me to remove it
please?

Kind regards,

Alan

You can't do anything about it. Some spammer is sending e-mails using
your e-mail address in the From header. The other problem is the stupid
admins that reject undeliverable e-mails by sending a NEW e-mail *after*
the mail session is over. They should be rejecting the undeliverable
message DURING the mail session so it the status goes to whatever
sending mail server is connecting to the receiving mail server rather
than blindly accept the message and then find out it is non-deliverable
and then stupidly assume the return-path specified by the spammer is
valid. Stupid spammers. Stupid mail hosts.

 

[Chris Mahoney]

In many cases it's the end-user's email client, rather than the server,
that sends the rejection messages. For example, the client I use can
send a rejection message if you flag the incoming message as spam.

 

[Brian Tillman]

In many cases it's the end-user's email client, rather than the
server, that sends the rejection messages.

Then stupid mail client. A message generated by a client is not a true
rejection.

 

[Chris Mahoney]

Out of interest, how "should" a mail client issue a rejection?

 

[Brian Tillman]

Out of interest, how "should" a mail client issue a rejection?

Rejections should be performed by the server hosting the mailbox during the
SMTP handshake at the HELO or EHLO command or, possibly, the MAIL TO
command. If the host named in those commands does not pass the accepting
server's tests, a rejection error (550 is the number, I believe) is issued
to the connecting router.

If a client were to issue a rejection, it would do so in a similar manner,
but the problem is that the rejection would then be to the client's mailbox
server. What good would that do? In fact, I don't see how it could ever
happen, since it's the client that initiates the connection, not the mail
server, and it's using POP, not SMTP protocols.

 

[Vanguard]

In many cases it's the end-user's email client, rather than the
server,
that sends the rejection messages. For example, the client I use can
send a rejection message if you flag the incoming message as spam.

So if it is spam, how do YOU (or your e-mail client) know that you are
sending the rejection to the correct sender? YOU DON'T and that is why
such auto-rejects are stupid. In fact, such rejections received by an
innocent (i.e., someone who never sent you the mail but gets your
rejection message) are themselves considered spam and are reported as
such to the spam blacklists. See SpamCop's policy on such stupid
rejections. Your client NEVER had the connection with the sending mail
host so you have no real way of identifying exactly what host sent you
the spam. You are generating a NEW and completely disconnected
rejection mail rather than rejecting the delivery DURING the mail
session (which then makes the *sending* mail host put an NDR
(non-delivery report) in the sender's mailbox). Mailwasher is one of
those products that provide such rejection methods: if spam then send a
bogus NDR. You aren't a mail server, your NDR is a *new* message and
not a mail session rejection which caused an NDR to be generated at the
sending mail host, you are wasting more mail traffic on worthless
rejections that will never reach the spammer, and you are likely sending
those rejections to innocents so your rejections are themselves spam
since the innocent never solicited for your rejection mail. Folks that
think Mailwasher's auto-reject bounceback is a good idea haven't spent
much more than a few seconds to cogitate what is really happening.