Celejar wrote:
>>On Thursday 24 August 2006 09:32, Celejar took the opportunity to say:
>>
>>>I use exim to relay mail (from a dialup box) via 'smtp.gmail.com' (resolves
>>>to 'gmail-smtp.l.google.com') as a smarthost. I have
>>>'*:user@???:passwd' in 'passwd.client', and 'port = 587' in
>>>'exim_config_remote_smtp_smarthost'. This configuration has worked for me
>>>for a while, but has "suddenly" (I may have done something, but I can't
>>>think what) begun to consistently fail, with messages such these:
>>>
>>>1GG8B8-0001Nd-Cf gmail-smtp.l.google.com [64.233.185.109] Connection
>>>refused 1GG8B8-0001Nd-Cf gmail-smtp.l.google.com [64.233.185.111]
>>>Connection refused 1GG8B8-0001Nd-Cf == xxxx@??? R=smarthost
>>>T=remote_smtp_smarthost defer (111): Connection refused
>>>
>>>The problem isn't with the gmail servers; I use these same settings with
>>>the MTA built into sylpheed and it's still working fine.
>>
>>What is exim_config_remote_smtp_smarthost? A file or a section of exim.conf?
>>The transport involved seems to be called "remote_smtp_smarthost". Are you
>>using a configuration front end? Perhaps some file suddenly isn't included
>>anymore. You can output the actual configuration with
>>
>> exim -bP transport remote_smtp_smarthost
>>
>>Check that it includes "port = 587".
>>
>>--
>>Magnus Holmgren holmgren@???
>> (No Cc of list mail needed, thanks)
>
>
> I ran exim with the -d option and saw that it was indeed trying to connect to port 25, not 587. I suppose I made some error related to the Debian specific config system, as Marc has pointed out. Unfortunately even after I convinced it to use port 587, it still doesn't work, failing with "530 5.5.1 Authentication Required". If people think this probably a Debian related issue, I'll take it to the Debian list.
>
> Celejar
>
The 'unique' manner of managing configuration is Debian-specific.
The problem is general:
- IF/AS/WHEN an MTA acts as a client to another MTA in MSA mode, *and* it
arrives on port 25, authentication is not ordinarily expected for traffic
destined TO the user-community on that server. It is seen as a 'distant'
correspondent - one of 'brazillions' who may have legitmate traffic for that
user community.
- However, IF/AS/WHEN said 'foreign' MTA attempts to submit traffic for OTHER
THAN users 'local' to the target host, it would ordinarily be treated as an
unauthorized relay attempt, and denied.
In order to be permitted to transit traffic to destinations NOT local to a given
host, one or both of two tests must ordinarily be satisfied:
- The host attempting to submit must be recognized (by IP, matching pem certs,
etc.) as an authorized relay source BY the intermediate host. Not bloody likely
for an ISP host you do not control!
- The host attempting to submit must 'authenticate' with a UID:PWD valid on the
intermediate host. This is exactly what your MUA ordinarily has to do when
submitting 'outbound' traffic, and may or may not be acceptable on port 25.
Port 587, with TLS, is a likely alternative.
Accordingly, the 'short answer' seems to be that for the intermediate
'smarthost' in question, you will have to configure Exim to behave much as your
MUA would do, i.e. use the expected port and protocol (TLS on 587?), and supply
BOTH a UID and Password valid for that host.
IF said host allows you to send mail when traveling and attached via some other
ISP's link, i.e with the correct UID:PWD, but a random source IP, then all
should be well. If NOT, then said host may *also* be allowing submission only
from valid UID:PWD who are also attached via its own 'backside' IP pool. Some
ISP do that, as it virtually guarantees that they can identify a rule violator
by their own MAC address logs and session timestamps.
You can test this environment with your MUA to see if that is so.
Applying the appropriate settings to cause Exim to meet the ISP smarthost
submission needs for authentication UID:PWD, unfortunately, IS Debian-specific
your case.
HTH,
Bill
