SMTP server while travelling

On Feb 28, 2005, at 8:02 AM, shellyk wrote:

> Is there some other type of SMTP service I can use, to preserve my
> ability to send email from my various email accounts? (some for my
> work, some for serving and administring a small mailing list). Are
> there recommended services or software, easy to set up, that I should
> check into?

A paid account at Fastmail.fm will give you SMTP access and they do
allow relaying. They also allow SMTP on abnormal ports to get around
firewalls, if that's a problem for you. This is a fairly simple method,
but a little bit on the expensive side.

<http://www.fastmail.fm/>

Alternately, you can set up Postfix on your own Mac to handle all your
email tasks. Guides for setup abound on the internet, and the main
thing you'd want to address is the possibility of someone else using
your computer to relay their email. This is simply handled by not
allowing anyone except for the local machine to access the postfix
service and/or Port 25.

<http://www.macosxhints.com/article.php?story=20031025022626398>

<http://www.postfix.org/>

The postfix approach is likely to be the most flexible, but you may
also end up with problems with either approach as you'll look more like
a spammer since you're relaying addresses. There are ways to mitigate
these problems, but they are not for the faint of heart, nor a good
temporary solution.

Good luck!

--Nik


  

I have a pobox.com account with SMTP enabled. They allow SMTP
connections on port 26 to overcome ISPs which block port 25.

At 7:02 am -0800 28/2/05, shellyk wrote:
>Is there some other type of SMTP service I can use, to preserve my
>ability to send email from my various email accounts? (some for my
>work, some for serving and administring a small mailing list). Are
>there recommended services or software, easy to set up, that I should
>check into?

If you have a gmail account you can use it for relaying.

The caveat is that the From: line will be your gmail.com address but the
reply to can be different ie your sympatico address. You need to set this
in your pop client rather than on the website - ie my webmail gmail has my
regular account name but when I am relaying from my Palm Mark/Space Mail
is set to have an appropriate Reply-To.

HTH

        f

At 7:02 -0800 2/28/05, shellyk wrote:

>Is there some other type of SMTP service I can use, to preserve my
>ability to send email from my various email accounts? (some for my
>work, some for serving and administring a small mailing list). Are
>there recommended services or software, easy to set up, that I
>should check into?

I use the little-known "XTND XMIT" command that can be found in
Qualcomm's POP3 server. It's enabled by default, AFAIK, since the
admin of the server I use didn't know about it until I asked about it
and it Just Worked. You do have to have an account on the machine
sending the mail, and you have to *check* mail at that account since
many stupidly broken mailers will send error messages to that account
(presumably using the return-path header or something) instead of
using the valid addresses in the headers.

The only problem I've had with this approach in several years is (I
believe) that it will generate error messages if you send mail with
addresses only in the Bcc: field. However, AFAIK the mail still gets
through.

~ Kiran <entropyio.com>
--

<http://www.io.com/contradance/> 857-928-9700 (cellphone)

I use each of my accounts' SMTP server. In other words, for mac.com
account I use smtp.mac.com, for my business account I use my service
provider's SMTP server. All of my accounts except one provide some sort
of secure access. Some ISPs block port 25, the SMTP port but it's
commonly mirrored on 587. If you don't have that option, you should
probably look into SSH Tunnel port forwarding.

If you set this up and have a more-or-less 1:1 relationship between POP
and SMTP, you should be fine.

At 15:01 -0800 2005-02-28, Kiran Wagle wrote:
>You do have to have an account on the machine
>sending the mail, and you have to *check* mail at that account

That's right; you do. However, the reason you cite is in error.

>since
>many stupidly broken mailers will send error messages to that account
>(presumably using the return-path header or something) instead of
>using the valid addresses in the headers.

You have that backwards. Stupidly-broken mailers might use some
address in the visible headers for error messages, but
correctly-operating mailers will use the address in the SMTP envelope
(which is also copied to the Return-Path: header line).

--Mark

On 2/28/2005 15:01, "Mike Cohen" <tidbitsmcdevzone.com> wrote:

> I have a pobox.com account with SMTP enabled. They allow SMTP
> connections on port 26 to overcome ISPs which block port 25.

Port 587 is also widely used (including by mac.com), and not as widely
blocked. It often requires SMTP AUTH.

  --John

I have a similar issue when using Entourage and some hotels connections or WiFi hotspots. Originally, I was using my comcast account email server to send my mail for both my comcast account and my business email. We switched biz email servers recently, so that problem went away, but I still have problems with Comcast.

What happens in this case is that Entourage doesn't even think about it...it just automatically rejects it. I've read a number of posts on other boards where other uses claimed they listened on the ports and Entourage didn't even try....I can't confirm or deny that. I'm not clear on what the criteria is as to why it works on some services and not others.

The error message I receive when it doesn't work is something along the lines of "Entourage does not support the specified method of authentication".

I have used postfix on occassion (when my biz email wasn't working either), but that had some challenges with it (probably user error on my side). Any one else tackled this successfully?

Alex

On 3/2/05 9:56 AM, "WILSONAT" <wilsonatcomcast.net> wrote:

>
> What happens in this case is that Entourage doesn't even think about it...it
> just automatically rejects it. I've read a number of posts on other boards
> where other uses claimed they listened on the ports and Entourage didn't even
> try....I can't confirm or deny that. I'm not clear on what the criteria is as
> to why it works on some services and not others.
>
> The error message I receive when it doesn't work is something along the lines
> of "Entourage does not support the specified method of authentication".

This is E'rage's odd way of saying "SMTP Auth is not working right".

The problem is, many public access points, (Hotel high-speed is REALLY bad
here) use a mail proxy system that totally fubars auth beyond use. The only
reliable ways I've found to send mail on the road are:

1) Use an SMTP server that allows you to use port 587. This of course
assumes that 587 isn't blocked. Some dialup services, (MSN!!!) block ALL
outbound SMTP ports that aren't their server. Morons.

2) Use Webmail.

john

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 7:02 AM -0800 2005/02/28, shellyk wrote:
>Is there some other type of SMTP service I can use, to preserve my
>ability to send email from my various email accounts? (some for my
>work, some for serving and administring a small mailing list). Are
>there recommended services or software, easy to set up, that I should
>check into?

        I have paid for a <http://pobox.com/> account for many years now,
and have been using their SMTP servers with that account for all of my SMTP
needs now for about a year - it seems to be working well, even for my
non-pobox.com return addresses. They cost about $12/year in batches of six
years when I last had a bill - maybe their prices have changed.

--
* Johann Beda - contact link: <http://public.xdi.org/=j-beda> *
* Johann's MostlyMac Computer Consulting - <http://mmcc.beda.ca/> *

> 1) Use an SMTP server that allows you to use port 587. This of course
> assumes that 587 isn't blocked. Some dialup services, (MSN!!!) block ALL
> outbound SMTP ports that aren't their server. Morons.
>
> 2) Use Webmail.

Or:

3) Use an SSH tunnel/VPN

Many hosts do allow you to create an SSH tunnel directly to your hosted
server, and then send mail from there. Pair networks <http://www.pair.com>,
for example, allows me to create an SSH tunnel to my web/mail server, thereby
allowing all SMTP traffic to go out through their SMTP servers over their
network. Plus, since I'm already creating a tunnel, I go ahead and send my
IMAP/POP traffic through the same SSH tunnel.

This has the added advantage of encrypting all communications over the
untrusted travelling network -- a particular advantage when you're in an
internet cafe or other environment known to have lots of people "sniffing"
your packets for passwords or other information.

SSH Tunnel Manager provides a convenient graphical interface to the
command-line SSH tunneling commands; I simply have mine run at startup to
transparently create all of my SSH tunnels.

<http://www.macosxhints.com/article.php?story=20030721022245232&query=ssh+tunnel+manager>

Take care,

--
David McLaughlin

At 2:11 AM -0800 3/4/05, Johann Beda wrote:

> I have paid for a <<http://pobox.com/>http://pobox.com/>
>account for many years now,
>and have been using their SMTP servers with that account for all of my SMTP
>needs now for about a year - it seems to be working well, even for my
>non-pobox.com return addresses. They cost about $12/year in batches of six
>years when I last had a bill - maybe their prices have changed.

I think pobox.com is going to be my method of choice, if my ISP
doesn't block the way out to their SMTP servers. Will test this week
and report back.

I'm interested in the discussion of ports and blocking/using them,
but sadly my technical savvy isn't up to following that part of the
discussion, or knowing if I can coax Eudora (or Apple Mali) to do use
alternative ports (if that's the way to say it.).

Is it then possible that my (Beijing-based, standard ISP) is blocking
the outgoing ports that I would need to accomplish what I want?

It also seems possible that no matter how I send messages, POP
servers in North America (where my email accounts are hosted) reject
messages going through this particular Chinese-based server
(over-broad blacklist problems?) so nothing I can do will help?

cheers,

Shelly

--On March 4, 2005 10:10:37 AM -0800 shellyk <shellykmac.com> wrote:
> I'm interested in the discussion of ports and blocking/using them, but
> sadly my technical savvy isn't up to following that part of the
> discussion, or knowing if I can coax Eudora (or Apple Mali) to do use
> alternative ports (if that's the way to say it.).
>
> Is it then possible that my (Beijing-based, standard ISP) is blocking the
> outgoing ports that I would need to accomplish what I want?
>
> It also seems possible that no matter how I send messages, POP servers in
> North America (where my email accounts are hosted) reject messages going
> through this particular Chinese-based server (over-broad blacklist
> problems?) so nothing I can do will help?

It may be the Chinese government. The Great Firewall of China is known for
blocking access to websites, it might be preventing use of mail server not
under it's more-or-less control too.

<http://www.pcworld.com/news/article/0,aid,116278,00.asp>

Most articles I see on it talk about web blocking, not other stuff. It is
possible for a firewall to analyze the content of a connection going out
and block it based on that. If the ISP's or government's firewall is doing
that then no amount of non-standard port use will fix it. You're back to
VPN or SSH tunneling.

At 03:01 PM 02/28/2005 -0800, Nik wrote:
>A paid account at Fastmail.fm will give you SMTP access and they do allow
>relaying. They also allow SMTP on abnormal ports to get around firewalls,
>if that's a problem for you. This is a fairly simple method, but a little
>bit on the expensive side.

This is actually a super-cheap method, because the account level required
for SMTP access is "member", which is a US$15.00 charge -- that's a
one-time lifetime charge, not annual. I often recommend this to people who
need roaming SMTP access. I've used this method while traveling to various
locations, including hotels, client sites, and homes of family and friends.
As long as I can get through the firewall to get to the Internet, it just
works. I never have to change my SMTP server. (Fastmail.fm is the MX for my
domain, paleo.org, so I get the SMTP as just one benefit of the service.
But I'd pay the $15 for reliable SMTP if I didn't already have it.)

Fastmail.fm offers both the port 26 option and the SSL alternate port
option. I haven't yet run into anyone blocking port 26 outgoing -- there's
no particular reason, since ordinary mail servers don't open port 26 and
thus it's of no use to spammers or worms. (OTOH, I have not traveled to
Beijing!) They also allow SSL connections, which uses port 465. I haven't
seen this port blocked either (same caveat). Setting up SSL can be a bit
hard to find in the Mac version of Eudora; you have to go to the SSL
settings panel (which is about four panels below Personalities, which it
should be next to), select the relevant personality, and change "SSL for
SMTP" to "Required (Alternate Port)".

At 10:10 AM 03/04/2005 -0800, shellyk wrote:
>It also seems possible that no matter how I send messages, POP servers in
>North America (where my email accounts are hosted) reject messages going
>through this particular Chinese-based server (over-broad blacklist
>problems?) so nothing I can do will help?

Hmm, not entirely sure what you mean. Do you mean that the recipient server
rejects the message based on IP address range? If so -- for example, if
recipient servers are examining the Received: headers for blocked IP
address ranges and blocking yours -- then any SMTP-based method for sending
your email is going to fail. You might be able to get around this by using
an anonymizer -- while typically used for shielding name and other contact
information, a side effect is to hide the originating IP address. However,
if they are only blocking the incoming SMTP port based on IP address range,
then going through a widely trusted server such as Fastmail.fm will get
around the problem.

The other option, as already mentioned, is webmail, since email sent from
web interfaces generally does not include the IP address of the originator.
Fastmail.fm also does this very well -- I still don't consider webmail
usable for daily chores, but at Fastmail.fm it comes close. And they
certainly allow multiple personalities and don't restrict your return
address -- after all, they get paid for providing email services to the
actual end users.

Edward

On Mar 7, 2005, at 7:46 AM, Kevin van Haaren wrote:

>> It also seems possible that no matter how I send messages, POP
>> servers in
>> North America (where my email accounts are hosted) reject messages
>> going
>> through this particular Chinese-based server (over-broad blacklist
>> problems?) so nothing I can do will help?
>
> It may be the Chinese government. The Great Firewall of China is known
> for blocking access to websites, it might be preventing use of mail server
> not under its more-or-less control too.

Is there any way to request that the government of China ADD my site to
their firewall blocking? I get a huge amount of comment spam from China
and I end up blocking each Chinese ISP's IP address range in my
.htaccess after they hit me. It would be much easier if their
government just prevented them from accessing my site completely ;-)

Here's how SMTP is supposed to work in the future. Many service providers
are moving towards ONLY permitting email submission on port 587, with
authenticated SMTP.

When you send a message from an email program, you MUST authenticate with a
username and password. RFC 2476 - "Message Submission" explains how this
should work. Many ISPs block outbound port 25, the standard SMTP port, for
the very good reason that it is very easy to abuse for spam. In order that
anyone can know that an email was correctly sent by the owner of the email
address, it should be submitted directly to the SMTP server of the domain
owner. That won't always be the ISP, so you need a way to get around the
blocking of port 25. RFC 2476 says that you should use port 587.

If port 587 gets abused, it will get blocked by ISPs. Therefore, port 587
should be protected in some way, so that it can't be abused. The method of
protection specified is that ALL connections on port 587 must require
authentication. In order to protect passwords from being stolen,
connections on port 587 must also be encrypted - TLSv1 is usually used.

So, if your ISP lets you use any old email address on their servers, even
if you are authenticated, then they're doing wrong. They shouldn't let you
do that, because they have no way of knowing whether you are permitted to
use addresses in domains that they don't control. They should only let you
use their domains.

If your ISP lets you connect to an SMTP server on port 25 - that they
control, then they're doing wrong. They should only let you connect to
their SMTP servers when you are using port 25. If they don't provide port
587 for domains that they control, then they're doing wrong. If they block
port 587, then they're doing wrong.

If your mail service provider doesn't let you use port 587, then they're
doing wrong. Ask them to set it up soon.

If your mail program doesn't support TLSv1 on port 587, then it's doing
wrong. Change it for one that does. Or, try using SSL on port 465 - but
that's only a temporary workaround, it's outdated.

Finally, make sure that you are using port 586 with TLS if you can. Service
providers often blame user inertia for supporting old standards. Don't let
your usage be their excuse.
--
Ian Eiloart
Servers Team
Sussex University ITS

At 11:07 AM -0800 2005/03/08, Ian Eiloart wrote:

>So, if your ISP lets you use any old email address on their servers, even
>if you are authenticated, then they're doing wrong. They shouldn't let you
>do that, because they have no way of knowing whether you are permitted to
>use addresses in domains that they don't control. They should only let you
>use their domains.
>
>If your ISP lets you connect to an SMTP server on port 25 - that they
>control, then they're doing wrong. They should only let you connect to
>their SMTP servers when you are using port 25. If they don't provide port
>587 for domains that they control, then they're doing wrong. If they block
>port 587, then they're doing wrong.

        No. I use DRAC (Dynamic Relay Access Control)
<http://mail.cc.umanitoba.ca/drac/> on mail.reppep.com. This is an
excellent option, as it requires no explicit client-support (no TLS,
no SMTP Auth, no unencrypted or reversible passwords on the server).

        After one of my users successfully *checks* mail for their
reppep.com, their IP is added to a small database maintained by
DRAC. For half an hour after that, Postfix will accept mail from that
IP, since it was known to belong to a valid user (recently). In this
window (which is updated on every successful check, so stays open
indefinitely), I allow my user to send email to/from any address,
since I trust them.

        DRAC is secured by the IMAP/TLS or POP/TLS password. SMTP
Auth requires a reversible password on the server for the
challenge/response negotiation, which I prefer to avoid (although
I'll probably do it soon, for user convenience). Additionally, DRAC
this works much better with dumb/PDA clients, which may not include
support for SMTP/TLS and SMTP Auth, but generally do checks before
sends, which is all that's required to fully support DRAC.


                                                Regards,


                                                Chris Pepper
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

At 7:31 AM -0800 3/9/05, Chris Pepper wrote:
> DRAC is secured by the IMAP/TLS or POP/TLS password. SMTP
>Auth requires a reversible password on the server for the
>challenge/response negotiation, which I prefer to avoid (although
>I'll probably do it soon, for user convenience). Additionally, DRAC
>this works much better with dumb/PDA clients, which may not include
>support for SMTP/TLS and SMTP Auth, but generally do checks before
>sends, which is all that's required to fully support DRAC.

DRAC is a standard POP(or IMAP) before SMTP implementation. I'll
admit that it seems to do this very well. But the hole with this is
many viruses (windows) are getting smarter looking for the mail
program's SMTP settings and using those. So after the user
authenticates to the server with POP before SMTP that IP that opens a
hole for that IP address to send as much mail as it wants for 30
minutes.

This can get even more problematic with a computer connecting via
NATed connection, it'll authenticate the public IP allowing any
computer behind the NAT to use the SMTP server.

I'll admit in practice that POP before SMTP works fine. But it has
holes. If spam has taught us anything it is if there are holes in a
system they will be exploited.

Nick

At 11:57 AM -0800 2005/03/11, Nicholas Barnard wrote:
>At 7:31 AM -0800 3/9/05, Chris Pepper wrote:
>> DRAC is secured by the IMAP/TLS or POP/TLS password. SMTP
>>Auth requires a reversible password on the server for the
>>challenge/response negotiation, which I prefer to avoid (although
>>I'll probably do it soon, for user convenience). Additionally, DRAC
>>this works much better with dumb/PDA clients, which may not include
>>support for SMTP/TLS and SMTP Auth, but generally do checks before
>>sends, which is all that's required to fully support DRAC.
>
>DRAC is a standard POP(or IMAP) before SMTP implementation. I'll
>admit that it seems to do this very well. But the hole with this is
>many viruses (windows) are getting smarter looking for the mail
>program's SMTP settings and using those. So after the user
>authenticates to the server with POP before SMTP that IP that opens a
>hole for that IP address to send as much mail as it wants for 30
>minutes.

        Pfui. If one of my users has an infected PC, it can relay
through me via DRAC, or through sending messages through Outlook
(which would be configured for SMTP Auth), or anything that allows
the person to send legit mail.

>This can get even more problematic with a computer connecting via
>NATed connection, it'll authenticate the public IP allowing any
>computer behind the NAT to use the SMTP server.

        Yep. AOL, feh; otherwise I'm not too concerned.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

At 8:23 PM -0500 3/11/05, Chris Pepper wrote:
>At 11:57 AM -0800 2005/03/11, Nicholas Barnard wrote:
>>This can get even more problematic with a computer connecting via
>>NATed connection, it'll authenticate the public IP allowing any
>>computer behind the NAT to use the SMTP server.
>
> Yep. AOL, feh; otherwise I'm not too concerned.

Don't go too quickly that its just AOL that uses NAT. I'm on the
telephone co's DSL network and I'm NATed. (Believe me I search
weekly for other options.)

Many smaller telecoms unfortunately use NATing. Plus you also have
to assume all of the individual users who have setup their DSL/Cable
connection behind DHCP w/ NAT.

Nick