Subject: Finding a working SMTP relayer

From: Jacob Palme <[email-masked]>
Date: Sat, 28 May 2005 19:00:02 +0200

When you are travelling, it is often a nuisance to have to
find out which SMTP relayer will work for sending your mail
before you can send any messages.

Before 1995, this was no problem, because then any SMTP
relayer was willing to relay any message. As an anti-spam
measure, this was stopped in the middle of the 1990-s.

Your local SMTP relayer might accept messages from the
outside if you log in to it with a password.

Or you might install an SMTP relayer on your own laptop - I
just tested getting postfix running on my (Mac OS X = Unix)
laptop to relay my mail and it worked, thanks to a useful
application "postfix enabler".

However, my mail could still not get relayed, until I
changed the postfix settings so that all outgoing mail was
sent to the SMTP relayer of my ISP. And the whole idea was
not having to find this out. Apparently, my ISP, and many
other ISPs, stop all outgoing SMTP calls to other than
their own mail relayer, probably to make spamming more
difficult.

Question: Is there a standard, or should a standard be
made, to use the DNS to find out what the domain name is of
the SMTP relayer in the network you are currently connected
to? With such a standard, mail programs might automatically
query the DNS to find out what the SMTP relayer is, and I
would not have to manually change the setting of my email
program every time I move from home to work or back.
-- 
Professor Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Ned Freed <[email-masked]>
Date: Sat, 28 May 2005 10:08:34 -0700 (PDT)

> program every time I move from home to work or back.

See the discussion with the subject  line "SMTP option for DHCPv6" on the
ietf-822 list. The various issues with such an option have been brought
out there, most of which are indepedent of the underlying mechanism
(e.g., DHCP). I will also add that the existing DHCP SMTP server 
option is IMO fatally flawed, in that it doesn't allow for specification
of either port numbers (essential) or domain names (highly desireable).

I will also note that (expired) draft-hall-email-srv-03.txt may be of interest
as part of this.

				Ned

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 28 May 2005 14:11:56 -0400

On 5/28/2005 1:08 PM, Ned Freed wrote:

>> Question: Is there a standard, or should a standard be made, to use
>> the DNS to find out what the domain name is of the SMTP relayer in
>> the network you are currently connected to? With such a standard,
>> mail programs might automatically query the DNS to find out what the
>> SMTP relayer is, and I would not have to manually change the setting
>> of my email program every time I move from home to work or back.

> I will also note that (expired) draft-hall-email-srv-03.txt may be of
> interest as part of this.

I'll just point out that the I-D is keyed to user identity and not local
topology. It would have solved Jacob's problem by automatically locating
the submission server associated with his email domain (the ISP's
public-facing submission server, if he was using an ISP account) but would
not have located a server on the "local" network (unless a "local" email
address were in use, of course).

I'm still wanting to see the I-D proceed but at this point I think that it
needs to be picked up by WG effort to go any further. Do folks think it's
worth pursuing, and if so which WG should it go into (keep in mind it
deals with submission, pop/imap and DNS all at the same time)?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 28 May 2005 20:14:40 +0200

> outside if you log in to it with a password.

See RFC2476 (http://www.ietf.org/rfc/rfc2476.txt)

port 587 is not blocked in most cases and this also works when SPF or
other mechanisms will be enabled in the coming years.

Greets,
 Jeroen

---

From: Ned Freed <[email-masked]>
Date: Sat, 28 May 2005 13:24:29 -0700 (PDT)

> deals with submission, pop/imap and DNS all at the same time)?

I'm all for proceeding with this document. IMO it solves an important problem,
although not, as you say, the one Jacob asked about.

				Ned

---

From: Graham Klyne <[email-masked]>
Date: Tue, 31 May 2005 12:37:36 +0100

>before you can send any messages.

Jacob,

I overcome this by using an SSH tunnel to my "home" SMTP relay.  SSH is 
usually (almost always?) an allowed protocol in foreign environments.

This not only avoids "hunt the relay", but has obvious security benefits in 
foreign/open network environments.  (Spam harvesting from wireless 
hotspots, anyone?)

#g
--

>program every time I move from home to work or back.

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

---

From: Ned Freed <[email-masked]>
Date: Tue, 31 May 2005 09:33:52 -0700 (PDT)

> foreign/open network environments.  (Spam harvesting from wireless

I do more or less the same thing myself - I tunnel all sorts of services,
including email, back to home base using SSH. And of course both
TLS/SSL and IPSEC can be used instead of SSH.

But this just begs the question of what the target audience is here. If we're
talking about a solution for a bunch of tech geeks who have a setup at home or
work or whereever to tunnel back to, then these sorts of thigns work fine. If,
OTOH, we're talking about a solution for simplifying things for J Random
Roamer, who typically isn't going to have something to connect the tunnel to,
then none of this is terribly useful.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 May 2005 21:47:59 -0400

Eric,

Since you have mentioned that draft, maybe it is time to ask the 
symmetric question again.  Ignoring a number of minor cases, 
there are two important cases of "how do I find an appropriate 
SMTP relay".  One is covered by the draft, and relates, as you 
say, to finding a server appropriate to the user's identity.

The other involves finding a server appropriate to the user's 
topology of the moment.    In theory, that  information can be 
delivered by DHCP.  It can even be supplied that way when DHCP 
has not provided the IP address for the user's host.   There is 
even a defined DHCP option for delivering SMTP server info.  As 
Ned notes, that option, as now defined, is deeply flawed for a 
number of important cases.   But, even for the cases in which it 
could be used, actual usage of the thing is very near zero. 
Some of that does have to do with DHCP: unless one makes a major 
excursion into the API business, and maybe even not then, the 
information needed to utilize DHCP properly is not readily 
available to mail clients at the right time, the refresh model 
is dubious, and there are other issues.

So the next question is "is there any serious interest in 
working on a 'how to find the SMTP relay/submission server 
appropriate to the local topological environment'?   This 
probably generalizes.  E.g., if one believes in HTTP caching 
proxies, finding the right local one raises some of the same 
issues.

     john

--On Saturday, May 28, 2005 14:11 -0400 "Eric A. Hall" 
<[email-masked]> wrote:

>>> Question: Is there a standard, or should a standard be made,
>>> to use the DNS to find out what the domain name is of the
>>> SMTP relayer in the network you are currently connected to?
>>> With such a standard, mail programs might automatically
>> I will also note that (expired) draft-hall-email-srv-03.txt
>> may be of interest as part of this.
>
> I'll just point out that the I-D is keyed to user identity and
> not local topology. It would have solved Jacob's problem by
> automatically locating the submission server associated with
> his email domain (the ISP's public-facing submission server,
> if he was using an ISP account) but would not have located a
> server on the "local" network (unless a "local" email address
> were in use, of course).
>
> I'm still wanting to see the I-D proceed but at this point I
> think that it needs to be picked up by WG effort to go any
> further. Do folks think it's worth pursuing, and if so which
> WG should it go into (keep in mind it deals with submission,
> pop/imap and DNS all at the same time)?

---

From: Ned Freed <[email-masked]>
Date: Tue, 31 May 2005 21:00:14 -0700 (PDT)

(previous copy's header got garbled; apologies for the duplicate)

> is dubious, and there are other issues.

Eric actually pointed this out in one of his responses (maybe to another
list - I'm having trouble keeping some of these threads straight).

The API situation would definitely have to change for serious DHCP provisioning
of applications to be viable. I do see some small signs of hope, however. For
example, in Mac OS X the location manager seems to be a place where DHCP
options and location-specific network application settings come together.

> proxies, finding the right local one raises some of the same

Very good point. These sorts of things definitely belong in the same category,
some of them more so than submit server addresses. Offhand I'd say the place to
start would be an option offering  a list of services and corresponding
servers/ports. Further elaboration would be needed, of course.

				Ned

---

From: Tim Bray <[email-masked]>
Date: Tue, 31 May 2005 21:18:55 -0700

One of the nice things about working for a big company (Sun in my  
case) is that they operate this big honking SMTP server that's  
password+SSL-protected and listens on a bunch of different ports.  If  
I were an indie again, I'd cheerfully pay a couple bucks a month for  
such a service; put a choke on it allowing no more than a couple  
hundred emails a day and that would stop the spammers.

I used to do the ssh trick too but this is less work and I've never  
been locked out of it once in the last year and a bit, and I'm a  
serious gipsy.

So, is there really a problem? -Tim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 31 May 2005 21:24:28 -0700

Ned,

>  I'm having trouble keeping some of these threads straight).

I keep thinking that there is a serious need for an email client that helps the 
dedicated user (high volume, long-term traffic) in terms of managing the daily 
load, facilitating dialogue, managing the long term storage issues, etc.  I 
believe those of us with that need today are indicators of a larger market need.

You've raised an aspect of thread management I hadn't quite connected with 
before, since my thinking has focused on on-going within-thread issues.  But I 
suspect there are a number of cross-thread issues, such as you suggest.

Sure wish there were a way to pursue this.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net