Re: [Exim] Relaying at ISP SMTP - ANSWERED

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Matthew Byng-Maddick
Dátum:  
Címzett: exim-users
Tárgy: Re: [Exim] Relaying at ISP SMTP - ANSWERED
On Sun, Nov 18, 2001 at 09:40:01PM -0500, Paul M Foster wrote:
> On Sun, Nov 18, 2001 at 07:42:37PM -0500, Richard Welty wrote:
> <snip>
> > Paul has already been given the clues he needed to solve his problem;
> > unfortunately, he's already made up his mind and isn't listening.
> So you're gonna give me clues, but no answers? Ach!


Yes. If you're not competent to be a mail admin, don't do mail!

> Look, at the beginning of this, I didn't know who Philip was (until you
> folks pointed it out). My apologies to Philip or anyone else who was


Did you read the specification? It has the name "Philip Hazel" on there.

If you didn't, perhaps you don't understand
a) how mail is processed in general
b) how mail is processed in this specific case.

> offended by my posts. And I have no particular wish to be argumentative.
> However, when I find a white rabbit and twenty people insist on telling
> me it's green, I must protest.


No, you're colour blind!

> The facts are these:
> 1. When you contact smtp.quillandmouse.com, you may get any of a number
> of XO mail hosts, selected presumably at random, or at least appearing
> so.


This concurs with pir's post of the round robin DNS.

> 2. It is unreasonable to assume that one would be able to relay through
> only a fraction of these, and that which one you connected with-- at
> random-- would determine whether relaying would be allowed or not.


Oh? is it? why should this be? You're making the assumption that the
admin of the remote machine is competent, and is running the same MTAs
and the same configurations. I don't see why that is any bigger assumption
than the assumption of ours you claim to be "unreasonable".

> 3. It is true that nothing in the SMTP dialog from the point of the
> first 220 message on has any bearing on whether relaying will be
> allowed. This according to RFC 2821 and according to the SMTP dialog for
> working and non-working examples.


Erm, SMTP AUTH? STARTTLS? What you seem to be missing is that relaying is:
a) defined in terms of the server
b) never asked for explicitly, the server decides whether or not to relay
based on whether it believes it is a mail that it will have to "relay"
and whether there is administrative authorisation for it to do so. (this
is different to there being authentication of any sort of the client,
though this must take place too).

> 4. It is true that the deletion of the "hosts_override" line from the
> previously posted config file eliminated the problem of arriving at an
> "endpoint host" as opposed to a "relay host". This is evident from the
> facts that a) no relaying was possible prior to that point; b) that was
> the only change made to the config file at that time; and c) relaying
> became the rule after that.


In this b is the only statement that is fact, everything else in here is
conjecture, and I don't see quite what you're trying to say.

> I can only assume that there is something (unknown) which occurs prior
> to the first 220 response from the server, which tells XO that I wish to


How?
>> IAC DO GET_ME_A_RELAYING_SERVER

<< IAC WILL
??

SMTP doesn't actually speak telnet, even if you can use the `telnet'
program to speak to an smtp server. Things that will occur before the 220
banner is sent:
  o Reverse DNS Lookup - This may well decide whether or not you can relay
  o Ident Check - Nothing should rely on the output of these to decide
                  anything, however they may be useful in tracing abuse.


> speak to a relaying server. Either by my transmission or the server's
> deduction. But whether that is true or not, it's clear that the eliding


Server's deduction is something else.

> of the "hosts_override" line from the config file did in fact make the
> difference, something which has been debated on this list.


No, your lack of understanding of mail is what has been debated on this
list.

Suppose I am a server who wants to send you mail. Let us say, I have
accepted the mail from a user('s MUA):

   "Hmm, I want to send mail to paulf@???, where do I connect
    to?"
   "DNS, get me the MX hosts for quillandmouse.com, please"
     "Sure, MTA, they are:
      - 7 inflexible.cnchost.com
      - 8 invincible.cnchost.com
      - 8 indefatigable.cnchost.com
      - 10 hood.cnchost.com"
   "DNS, can you tell me what the IP address of inflexible.cnchost.com is?"
     "Sure, MTA, it's 207.155.252.24"
   "Thanks DNS".


   "Kernel, can you open me a socket to 207.155.252.24 port 25, please?"
     "Sure, MTA, here's a file descriptor"
   [smtp session continues, and mail gets delivered]


Now, that is the normal process for sending a mail onwards. If we're going
to a smarthost, it's slightly different.

   "Hmm, I want to send mail to paulf@???, where do I connect
    to?"
   "Oh, I've been told to use a smarthost of smtp.quillandmouse.com I'll go
    there"
   "DNS, get me the A records for smtp.quillandmouse.com, please"
     "Sure, MTA, they are:
      - 207.155.248.31
      - 207.155.248.12
      - 207.155.252.47
      - 207.155.252.31"
   "Thanks DNS".
   "Kernel, can you open me a socket to 207.155.248.31 port 25, please?"
     "Sure, MTA, here's a file descriptor"
   [smtp session continues, and mail gets delivered]


Now, 207.155.248.12, 207.155.248.31, 207.155.252.31 and 207.155.252.47 are
configured to allow relaying outbound for their own ipaddresses, as they
are advertised smarthosts (assuming the admins are competent).

The inbound MXs for quillandmouse.com 207.155.252.24, 207.155.248.15,
207.155.248.27 and 207.155.252.6 are not. As you can see here, they are
a different set of machines.

I neither know, nor at the moment, care, why your configuration doesn't
work, but to be honest, the spec has some good examples of how to set up
configurations to smarthosts, generally doing routing with a domainlist
router.

> Now, if someone has a reasonable answer besides "it's the server,
> stupid!", I'm all ears. And if you can prove that any of the assertions
> above are _not_ true, I will happily apologize for my seeming arrogance.


I await your apology. When you understand
a) the RFC
b) the Exim specification
a bit more, then argue this with people.

MBM

-- 
Matthew Byng-Maddick         <mbm@???>           http://colondot.net/