[Lilux-help] Port 587 the solution?

[Patrick Kaell]

Yes, I was a bit emotional in the last posts, and I wasn't always fair 
resp. did not accept some facts to prove my point. Now I see that I 
agree with Eric concerning important technical points, even if we have 
different philosophical views.

Some may think that the subject may now be OT. Ok, these people can skip 
this mail if they want. I believe that we are all concerned by mail 
problems and that the last posts may also have put some facts in a new 
light, so it may be worth to keep some key elements of it.

I agree that we should give up some freedom to get a bit more security. 
There are already infected PC's (modificated Netsky worms) who are 
sending "propaganda from the political right wing" to anybody using my 
E-Mail address as sender. I know this because I get sometimes "mail 
delivery errors". This is not nice, and I am ready to rethink and 
reconfigure my system to make life harder for these abuses. But I must 
get informed by the provider to prepare myself in advance.

I did not mention it anymore in the last post, but blocking port 25 was 
not a problem for me at all (as I wrote the 28 May in this list). My 
girlfriend couldn't send any mail as long as I was not there (because I 
could't prepare myself in advance) but after I had identified the 
problem I simply used the alternative port 587 (RFC conformant) to send 
mail. I was glad that my mail provider Puretec supported this.

So blocking port 25 was not the problem. But you need a mail provider 
who supports this alternative port.

Eric, I know I was a bit unfair by saying that nobody uses the ISP 
provider's relay to send mail. There are many, I know. But there also 
people who send mail through their mail provider's SMTP server, which is 
perfectly legitimate.

Blocking port 25 and relaying customer's mails through the ISP 
provider's server also makes sense at the moment. The ISP can filter the 
mails for worms (which might otherwise not be possible) and can not only 
log the connections but also the mail headers of all outbound mail 
(although some packet filters might also be able to do this (to look 
inside IP packets)). And you are right: There is currently no worm which 
would send through the ISP relay. I can't you show one, because I know 
of none. But as you said yourself: The internet today is not the 
internet of 10 years ago. You will see that the internet of tomorrow 
will not be the internet of today. In other words: The ISP mail relay 
solution you are using is only a temporal solution. As soon as this 
technique will be in widespread use (which will be the case if ISPs 
block port 25 and only allow access to their own mail relay), the worms 
(and the spammers who exploit remote controlled infected systems) *will* 
abuse it (we both agree that this will be trivial).

The SMTP protocol dates back to 1983 and is not suitable anymore for 
today's internet. But I dislike temporal solutions that have been 
invented by several ISPs. I want a definitive solution that has been 
developed by the internet community. Actually this already exists: SMTP 
over SSL. It has already been implemented my all major mail clients 
(including Mozilla, Eudora and even Outlook). Now is the time for the 
ISPs to implement this community developed standard. And you do not need 
port 25 anymore, as SSL uses port 443!

I wonder if PT actually guarantees you the "relay service", or if they 
were just to lazy to configure their SMTP server otherwise (as I know PT 
I suspect that the latter might be true).

Also remember that any PT customer is able to send mails using your ETH 
address though the PT relay. Thus even by examining the mail header, I 
can not verify that this mail is really coming from you (if you do not 
signature your mail)! As long as your mail has not been relayed by ETH's 
mail servers the authenticity of your mail is questionable. Ok, I know 
that it is possible to fake the headers by spoofing ETH's IP addresses, 
but this is outside the possibilities of infected PCs and spammers.

We need SMTP authentification over SSL, there is no way around this. The 
other solutions are temporal at best.

Prepare that PT will block all non @pt.lu mails sometime in the future. 
Hope that they will warn you on time!

Greeting, Patrick Kaell