Re: more on the outgoing smtps (port 465) ...
- From: Mikko Nahkola <mnahkola@xxxxxxxxxxxxxxxxxxx>
- Date: Tue, 04 Apr 2006 07:49:24 GMT
On 2006-04-03, Per Hedeland <per@xxxxxxxxxxxx> wrote:
<mnahkola@xxxxxxxxxxxxxxxxxxx> writes:
On 2006-03-31, Per Hedeland <per@xxxxxxxxxxxx> wrote:
<mnahkola@xxxxxxxxxxxxxxxxxxx> writes:
On 2006-03-30, Per Hedeland <per@xxxxxxxxxxxx> wrote:
<mnahkola@xxxxxxxxxxxxxxxxxxx> writes:
Although, trying to fit AUTH_OPTIONS=pOh well. There's always stunnel.That's probably your best bet.
Hm, that's a server-side thing and pointless with SMTPS (the condition
is always fulfilled), though it does work right then too IIRC. Why would
it be a problem with stunnel?
Not so much with stunnel as with the _other_ mailertable entry that goes
to port 25 and might not get STARTTLS.
I still don't understand - mailertable is a client-side thing, what has
it got to do with the server having AUTH_OPTIONS=p? And where is the
difference for this port 25 connection compared with not having stunnel
in the picture?
Well. I found several configuration examples on the 'net where
AUTH_OPTIONS=p was considered important so as to not accidentally pass
the credentials in an unencrypted connection, even as a client.
And we're talking about a setup where sendmail does need to perform
authentication (LOGIN, no less), when relaying to at least some ISPs'
mail servers. And the same LOGIN credentials are also used for the
account's IMAP mailbox, yes, so letting them loose on the 'net isn't a
great idea.
Now, were the examples incorrect and AUTH_OPTIONS isn't looked at (that
way) when in the client role?
If not, how does sendmail know that p is satisfied if it talks to the
big server via stunnel?
Why do you need client-side SMTPS anyway, there aren't any MTAs that do
SMTPS but not STARTTLS, are there?
If it were just the MTAs it were simple. But, would you guess that my
parents managed to get an ADSL connection package from an ISP, with them
already having dialup access _and_ existing mailboxes at another ISP
or two, and all.
Given that there's a fairly strongly-worded order from the local
communications regulator about fighting spam by blocking outbound port
25 with consumer broadband at least by default... well.
( http://www.ficora.fi/englanti/document/FICORA112004M.pdf and
implementation notes in http://www.ficora.fi/englanti/document/SMS11.pdf )
Bizarre stuff - I guess it's good that "authorities" take an interest in
preventing spam, but they have no business regulating *how* it should be
prevented, such as deciding that a "consumer" doesn't need inbound or
outbound SMTP.
Well, that's the political question, isn't it? Let's not go there now.
But in the case of your parents, they hardly have a need to connect to
another ISP's mail server just to send mail, do they?
The ADSL provider's mail server is picky about envelope-sender, which
is... /inconvenient/ ... when they want to use their old mail account at
another ISP.
(Yes, this does require one of the sender-checking things for choosing
the relay.)
And they don't
need SMTP to read their mailboxes at that other ISP.
Correct, but sending mail from that address is another thing (if done
right, at least.)
Oh well. I already told them to get new mailboxes from the broadband ISP
anyway. The first few are no extra charge with the ADSL so...
--
Mikko Nahkola <mnahkola@xxxxxxxxxxxxxxxxxxx>
#include <disclaimer.h>
#Not speaking for my employer. No warranty. YMMV.
.
- Follow-Ups:
- Re: more on the outgoing smtps (port 465) ...
- From: Per Hedeland
- Re: more on the outgoing smtps (port 465) ...
- References:
- Re: more on the outgoing smtps (port 465) ...
- From: Per Hedeland
- Re: more on the outgoing smtps (port 465) ...
- From: Mikko Nahkola
- Re: more on the outgoing smtps (port 465) ...
- From: Per Hedeland
- Re: more on the outgoing smtps (port 465) ...
- Prev by Date: Re: milter-regex and blocking HTML
- Next by Date: Re: default value for greet pause
- Previous by thread: Re: more on the outgoing smtps (port 465) ...
- Next by thread: Re: more on the outgoing smtps (port 465) ...
- Index(es):
Relevant Pages
|