Re: [Exim] AOL - SPF - and EXIM

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Exim User's Mailing List
Dátum:  
Címzett: Suresh Ramasubramanian
CC: Exim User's Mailing List
Tárgy: Re: [Exim] AOL - SPF - and EXIM
[ On Saturday, June 12, 2004 at 17:50:25 (+0530), Suresh Ramasubramanian wrote: ]
> Subject: Re: [Exim] AOL - SPF - and EXIM
>
> On Fri, Jun 11, 2004 at 10:04:38PM -0400, Greg A. Woods wrote:
>
> > If you reject at RCPT time based on your dislike of the HELO parameter
> > then you're only confusing the sender, at best. You're saying at the
> > protocol level that you don't like that recipient address then nine
> > times out of ten you're going to end up making the sending user think
> > they mis-typed the address or that their friend no longer has a mailbox
> > at your domain.
>
> Connect from a roadrunner cablemodem to your MX
> EHLO yahoo.com
>
> What do you get then?


You mean to _my_ MX? :-)

Since when was it legitimate for any roadrunner cablemodem user to have
a true MTA running on their home PC? :-)

However to play it out, i.e. if that's what you mean then indeed you'll
get something very much like the following (since it doesn't really
matter where you connect from so long as it's not from my own home
network or one of the very few other addresses I "trust" and which I
know will send me a bogus greeting name):

    $ telnet mail.weird.com 25
    Trying 204.92.254.2...
    Connected to mail.weird.com.
    Escape character is '^]'.
    220-most.weird.com Smail-3.2.0.118 (#1 2004-May-31)
    220-ready at Sat, 12 Jun 2004 14:23:13 -0400 (EDT)
    220 ESMTP supported
    EHLO yahoo.com
    501-fatal error while validating 'EHLO' host name 'yahoo.com'.
    501-connection rejected from admin.aci.on.ca remote address [205.207.148.250].
    501-Reason given was:
    501-  no DNS A records for the hostname 'yahoo.com' match the address
    501   [205.207.148.250]
    quit
    221 2.2.0 most.weird.com closing connection
    Connection closed by foreign host.


Now if you try that to some other less strict mailer that I help manage
(I'll temporarily turn off hostname verification on my test server as an
example :-), then you'll get something like this:

    $ telnet proven.weird.com 25
    Trying 204.92.254.15...
    Connected to proven.weird.com.
    Escape character is '^]'.
    220-proven.weird.com Smail-3.2.0.118-Pre (#17 2004-May-31)
    220-ready at Sat, 12 Jun 2004 14:26:03 -0400 (EDT)
    220 ESMTP supported
    EHLO yahoo.com
    550-You are not permitted to send mail from
    550-yahoo.com(admin.aci.on.ca[205.207.148.250]).
    550-All SMTP connections from your server have been blocked by the postmaster
    550-at proven.weird.com.
    550-
    550-Please note the following additional important information:
    550-
    550-  You are not a valid user of the domain yahoo.com!
    550-
    550-There is a serious error of some kind at your end which we cannot correct
    550-or compensate for at this end.  Please forward this message in its
    550-entirety to your own LOCAL <postmaster> and ask them to correct the
    550-problem for you.
    550-
    550-Postmaster@???:  Please contact
    550-<postmaster@???> (via an unblocked server of course!) if you
    550-need assistance in resolving this issue.  You must include your IP
    550-number, given above, in order to receive any help at all.   Including
    550 this entire status reply is ideal.
    quit
    221 2.2.0 proven.weird.com closing connection
    Connection closed by foreign host.


(the "additional info" above is a string included in the list of
patterns of hostnames to reject outright)

If you connected to anyone using a DNSBL that listed the source IP as a
dial-up/dynamic address, and who doesn't reject obviously forged
hostnames such as "yahoo.com", then you'd get an immediate reject
response mentioning the DNSBL specifics.

> 5xx'ing anywhere other than rcpt to has the unfortunate effect of having a
> bunch of broken MTAs that'll treat it as a tempfail and hammer back the
> message at you. Microsoft mailservers, virus smtp engines ...


That was just barely true six years ago. Today it's even less true.

In recent months (i.e. since about February of this year) my own mail
server has received connections from on average about 200,000 to 400,000
unique sending systems every week (with an average of about 400,000
connections per day for most of those weeks). To date my mail server
has refused a great number (~70%) of them at HELO/EHLO time. I've not
had to firewall a single one of them for the kind of misbehaviour you've
described. Not even _one_.

(I don't know how many correctly generated an immediate DSN and how many
eventually retried the same transaction again -- though that is
something I'd like to find the time to research. I also don't know how
many were disuaded from an immediate retry by my 4-second error delay,
though I do know that none were causing anything even remotely
resembling a DoS attack.)

BTW, permanent reject response codes (5xx) sent at MAIL are just as
effective for most true SMTP MTAs I know of. Doing the same at the
end-of-DATA (.) command is also usually effective, though there are
definitely problems with rejecting the DATA when the sender is just an
MUA (e.g. especially M$-OE, though sadly even Mozilla Thunderbird gets
confused too, and IIRC even the latest Eudora is rather stupid about
handling anything but 2xx responses at any time).

I.e. please don't confuse the sad sorry state of many MUA client-SMTP
(i.e. "submission") implementations with the majority of true MTAs.
There are lots of half-baked SMTP implementations in true MTAs to be
sure, but none even remotely so bad as the average MUA.


> Our error message returns a url like
> http://spamblock.outblaze.com/[some-code] - that has a detailed explanation
> for those who care to read it. Tends to minimize the confusion part of the
> issue I guess.


That's a good thing for certain. (I have considered adding a similar
"contact_url" setting for Smail so that it can do the same in a runtime
configurable manner...)

However it'll only help if the sender's mailer actually includes _all_
of the response text in the DSN (many only include the first line, and
some include none at all). Note that failing to include any or all of
the response text in a DSN isn't really a violation of any strict
requirement either (unfortunately :-).

It'll also only help if the sender's mailer doesn't (also) interpret the
response code just in case the response text is meaningless or in the
wrong language, etc. I.e. if you send a 5xx response at RCPT time then
the sender's mailer will invariably tell them that particular recipient
address is bogus, and it will often do so in _their_ own language, and
so even if your response text is included in the DSN, they perhaps won't
even be able to read it, let alone understand that it means nothing
about the recipient address. Sending a 5xx about the HELO/EHLO command
after each RCPT command is confusing at best and just plain stupid at
worst.

One "advantage" of getting lots of backscatter like I've been getting is
that you get to study thousands of different kinds of bounce messages,
but try it for yourself (with as many variant types of sending SMTP
software you can find) if you don't believe me.

--
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>