[exim] a large number of domains fronted by Exim are refusin…

Top Page
Delete this message
Reply to this message
Author: Exim User's Mailing List
Date:  
To: Exim User's Mailing List
New-Topics: RE: [exim] a large number of domains fronted by Exim are refusingbounces...
Subject: [exim] a large number of domains fronted by Exim are refusing bounces...
An extremely large number of domains fronted by Exim are now refusing
bounce messages (i.e. empty envelope sender addresses). This seems to
be some relatively new thing (last few months?) that many large hosting
providers are doing -- some claim to be handling as many as 70,000
domains or more.

Despite attempts by their very own customers to reason with them, and
despite listing them at dsn.rfc-ignorant.org, they are still refusing to
accept any bounce messages, even to <postmaster>. Worst of all the
reject comes only at the end-of-DATA so one cannot even do a callout
verification against them (not that _I_ would do that :-). For example,
from one of at least three big hosting companies doing this:

    $ telnet lunarpages.com 25
    Trying 216.193.194.188...
    Connected to lunarpages.com.
    Escape character is '^]'.
    220-pluto.lunarpages.com ESMTP Exim 4.44 #1 Thu, 16 Jun 2005 20:10:07 -0700 
    220-We do not authorize the use of this system to transport unsolicited, 
    220 and/or bulk e-mail.
    HELO building.weird.com
    250 pluto.lunarpages.com Hello [UJUiEAVX4GzqE5sximQBl/mw0WDypclTRTF53Mz5G18r0FHufwzDL0QR+O42swlJCX9RVtZlD5bsj9ojgqTLZQ==] at building.weird.com [204.92.254.24]
    MAIL FROM:<>
    250 OK
    RCPT TO:<postmaster@???>
    250 Accepted
    DATA
    354 Enter message, ending with "." on a line by itself
    Subject: bounces for lunarpages.com are not deliverable

    
    bounces for lunarpages.com are not deliverable

    
    .
    550 Administrative prohibition
    quit
    221 pluto.lunarpages.com closing connection
    Connection closed by foreign host.


Direct replies from staff at lunarpages.com confirm that it is their
policy not to accept any bounce messages. If only they were the lone
ones who have implemented this policy, but sadly they are far from
alone.... Others I don't mind mentioning are penguinhost.net and
truroot.net, but there are more to be sure. (Demon.nl seemed to be
doing it last fall, but they seem to have stopped since, thanks!)

I suspect the main reason they do this is that these hosting providers
have customers who don't originate much e-mail from their servers and so
they don't mind rejecting bounces. The problem is that any mail
originated with the sender address domain being the hosted domain must
be returnable to the hosted domain. Unfortunately at least some of
these providers, including lunarpages.com, don't seem to be offering
SMTP-over-SSL nor SUBMIT/STARTTLS, so their customers cannot use their
hosted domains as outbound relays (yet) either.

However this is causing a huge amount of havoc with my ISP clients who
provide home connectivity to many of the users of many of these domains.
We do not like having to manually handle double bounces, but neither do
we wish to prevent our users from using their hosted-domains in their
sender addresses (nor is it possible with most common PC-based MUAs to
use a different envelope sender than the FROM address -- though I'm
eager to hear of any way to do that in any MUA).

In any case whatever feature it is in Exim that allows sites to
implement such a blatantly stupid and damaging policy really needs to be
completely removed, and quickly; though I have no idea how to convince
these abusers to upgrade to a version that prevents their trashing of
the protocol. Hopefully their customers will put enough pressure on
them to accept bounces, but so far that doesn't seem to be happening.

Exim should be coded in such a way as to make it as impossible as can be
for fools like these to disobey these most fundamental requirements in
the protocol.

As I think we all know by now rejecting bounces doesn't stop, or even
curb, e-mail abuse -- all it does is to cause major damage to e-mail
reliability and if this practice persists it will completely destroy the
public's already poor perception of e-mail usability and utility.

-- 
                        Greg A. Woods


H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>