[Dshield] RE: ISP's not blocking egress 25/tcp

James C. Slora Jr. Jim.Slora at phra.com
Mon Jan 26 23:03:31 GMT 2004


I'll start fresh because my first post was too vague on the useful stuff and
made an inappropriate suggestion basically that spammer techniques can help
with configuring a remote corporate client.

ISPs blocking outbound 25 to servers other than their own is fairly
desirable. It cuts down on spam and virus mail a little bit, and does not
block what I consider the most desirable mobile corporate configurations.
There are pros and cons to every configuration, and every single one leaves
a different set of possibilities open for spoofed addresses in spam and
viruses. I won't even get into the specifics of each here - this will be
enough of a blowhard post already. SMTP is not even close to perfect no
matter how you slice it.

If you insist on using your own SMTP server for remote users, you could
always listen for SMTP on a port that is not blocked by the remote ISP or
set up a VPN for email access only.

The main barriers I have encountered to mobile corporate accounts using a
remote ISP's mail server while maintaining a corporate identity have been
AUTH and "POP3 before SMTP". Neither is too difficult to work with.

1) For a corporate user trying to behave corporately while getting access
from a remote ISP, the normal procedure might be to use the ISP SMTP server
and the corporate POP3 server - this avoids opening the corporate server to
relay from oddball sources, and works with (rather than against) any
possible ISP restrictions agains SMTP connections to foreign servers.

2) For "POP3 before SMTP", set up two accounts in the mail client - (1) that
uses the ISP's POP3 account to check mail but has the "email address" field
set up as the corporate mail address, and (2) the other with the corporate
POP3 server account and the ISP's SMTP server (with either the corporate
address or the ISP-provided address) . Do a "receive all" then a "send all"
instead of the standard Send/Receive. There are many variations of this
theme - customize to suit the way you want to work. Just make sure that the
user always checks the ISP's POP3 account before attempting to send mail.

3) Many ISPs are switching from "POP3 before SMTP" to SMTP AUTH to cut down
on bogus mail sent by viruses and spammers. POP3 before SMTP leaves the
connection open to abuse once the user has received any email at all. AUTH
is more restrictive overall because it requires each SMTP session to
authenticate, but it is actually easier for roaming corporate users to work
with at the client end. In this case, set the POP3 server to the corporate
server (I don't know of any ISPs that block POP3), and use the ISP's SMTP
server with SMTP authentication information. Use the corporate email address
in the regular "email address" field, even though it differs from the AUTH
account.

These methods are useful because they work with the relaying restrictions
imposed by both the corporate server and the ISP. The ISP only relays mail
from a properly authenticated account, and your corporate server does not
have to allow relay from foreign and possibly dynamic addresses.

I do not have any workaround for bypassing AUTH itself. AUTH can be a useful
check against abuse, and I would not promote any workarounds against it if I
knew of any.

AUTH itself does not preclude sending a message from a different address,
though, once you are authenticated. AUTH is account/password, not
address/password (even though the account may be based upon the address).

Some mail servers might be configured to compare "From" and "Return-Path"
addresses against the AUTH account as the spam battle continues to escalate
(even though this appears to violate AUTH's purpose of authenticating
submission, not authorship).

**** In these cases I advise the user to work with their ISP rather than
against it, and ask the helpdesk for special accomodation for accessing
corporate accounts ****.

These are the cases where there are some workarounds - I would have to
research them from scratch again starting with Google like anyone else
could, and in any case it is better to cooperate with the ISP to avoid
unpleasant surprises. I apologize to everyone for even mentioning the
existence of workarounds because they are a distraction from the preferred
courses of action (and because they could just as easily be abused by
viruses and spammers).

Some viruses use the Outlook or Outlook Express settings of the user in
order to send mail (well documented), so I believe they could take advantage
of AUTH settings anyway (not tested or verified). Spammers will certainly
defeat SMTP AUTH just like they did with "POP3 before SMTP". It is built in
to email clients that are already open to compromise. AUTH is usually
transmitted in the clear, so it is pretty trivial to sniff it. It is also
open to dictionary attacks and other mischief. But it provides some measure
of screening for right now at the ISP level. IMO AUTH is worse than
worthless for protecting corporate mail accounts and servers, but your
mileage may vary.

This is how things make sense to me, and how they have worked for me. They
might not work for you. And everything I said might be dead wrong.
 I am not authoritative about anything, and no statement should be trusted
without satisfying yourself that it's true.





More information about the list mailing list