james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Hoffmann ...@byteaction.de>
Subject Re: POP3 and other handlers ...
Date Mon, 24 Jul 2006 00:28:03 GMT
Hi,

Am Montag, 24. Juli 2006 01:27 schrieb Noel J. Bergman:
> Something more important: I am -1 on the current code.  The technical
> justification for vetoing this change is that we are tracking only the IP
> address.  One person on a non-routable subnet authenticates via POP3 or
> IMAP, and everyone else going through the same gateway router gets to use
> the now Open Relay?  

this is how POP-before-SMTP is done, and how other mailservers implement it, 
and how an admin would expect it to work. You can read the explanation about 
a different project and how it handles this here: 
http://popbsmtp.sourceforge.net/manpage.shtml

> Better would to be to maintain {ID, IP}-tuples. 
> Although that would be more difficult, or perhaps less useful, in virtual
> user table situations, since the POP3 USER and the SMTP MAIL FROM would be
> different, it would be better than creating Open Relays; 

exactly. Then again the question at hand is why implement it different from 
what the System Administrator would expect?

> especially Open 
> Relays in a way that most admins would find every difficult to track down,
> and which most Open Relay probes would not detect.

Pop before SMTP is a proven technique implemented in almost all mailservers 
out there on the open-source market. It is a common solution to people who 
already have had a server with users on it, and have to open access to the 
server to a broader range of people. One example:

A System Administrator of a small company has so far blocked access to his 
mailservers port 25 at his firewall. His ISPs Mailserver had his backup MX 
Record. He would then allow connections to port 25 on his mailserver from his 
ISPs Mailserver solely. His ISP promised, that he would do all spam 
prevention available. The Systems Administrator felt safe and sound, and did 
not think about further security measures.
The Day comes though, where sales who are roaming frequently need to send 
E-Mails. So he decides to install a VPN Gateway and have his sales people 
connect to the vpn and then lets them send E-Mails. Everything is still fine.
The Company is fast growing and in the consulting business though. So a 
Consultant is at a customers site, and VPN Access is blocked because of 
security measures, or whatever reason. He needs to send E-Mails in the Name 
of his Company and the Company he is consulting for. Because the 
Administrator has not implemented SMTP-AUTH before, he is having a huge 
problem. Either reconfigure 5000 Notebooks, to make use of SMTP-AUTH (Because 
of Data Restrictions Policy he does not have a record of the Passwords, so he 
has to reset them too). He cannot open the Server to the broad world without 
opening an Open-Relay. So he searches the Net, and reads about POP/IMAP 
before SMTP. This sounds like the perfect solution for him. After a 
successful Login from a certain IP the IP is opened for a short Timeframe and 
allowed to send E-Mails from. This solution is right on the money for him.

Tracking down, from where spam was send, is not hard either. He greps for the 
IP sending spam inside his log files, and finds the user who has 
authenticated from that IP. And the user must have a Spam Trojan on his 
Notebook, or must have given the information, that the Server is no open to 
send E-Mail from. In bothe Situations it, on the other Hand, helps the 
Administrator to track other Problems down, instead of hindering him.

And no Matter what, after the period is over, and no further successful logins 
were recorded, the relaying is denied after that. So even if you really come 
to the close to zero probaility situation where Spam is sent over an 
authorized ip, it is only during the specified timeframe.
 
-- 
Kind regards

Juergen 



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message