[Lilux-help] port 25 blocking by ISPs

[Patrick Kaell]

Brent Frère wrote:
> Brent, back from Spain, and probably out of sync:
> 
> Patrick Kaell a écrit :
> 
>> Eric Dondelinger wrote:
>>
>>> I've got LuxDSL. I constantly send mail from here with other
>>> domains than pt.lu. mailsvr.pt.lu relays it for me - as I'm
>>> on the P&T network. As you know about SMTP servers, I'll just
>>> say "smarthost".
>>
>>
>> Now, mail coming from mailsvr.pt.lu do not need to be from a @pt.lu 
>> address, right? It can be @sex.com and so on? Until now it was enough 
>> to block dialup address ranges in a Black List. Now it is neccessary 
>> to add mailsvr.pt.lu to the Black List, to be protected? A worm on 
>> your PC can send a mail to anybody using anybody's mail address using 
>> mailsvr.pt.lu. And the worm does not need to be ultrasmart to find the 
>> hostname mailsvr.pt.lu in the config files of your mail client.
> 
> 
> Eric is right: "mail coming from mailsvr.pt.lu do not need to be from a 
> @pt.lu address". Plan-Net has customers using also EPT mail servers, and 

I think there may still be confusion about this. I know that this works. 
(As you can see in the last posts, I already looked at the headers of 
some mails on this list to see that EPT relays everything coming from 
their own network). I was only sarcastic. I have no problem with the 
technical understanding of this. I just have a problem seeing why this 
method actually should be superior. Nobody could explain this to me yet.

Thibaut Britz sent a mail on 3 July on this list through ETH's SMTP 
server with a '@yahoo.com' From address to prove something I already 
know. What he doesn't know is that even if ETH's SMTP server happily 
relays such stuff, many receiver's servers will drop it *immediately*. 
Look at a large freemailer in Germany: GMX. They drop everything whith 
'@aol.com' and '@yahoo.com' From addresses that were not sent through 
AOL's or Yahoo's SMTP servers. You may think that this may be harsh... 
But look at:

http://www.theregister.co.uk/2004/07/05/sender_authentication/

Caller ID goes in the same direction. Sending throught your ISP's mail 
server may work now, but it will dissapear just like 'open relays'.

> I confirm this works. The protection you have is that EPT closes access 
> to e-mail services to customers emitting large amount of e-mails. I 
> don't know how they detect it, but they indeed switch off e-mail 
> forwarding services to identified customers that are suspected to have 
> e-mail worms or are abusing the e-mail service (spamming). I had a 
> customer complaining to Plan-Net about this, and it was verified as 
> being done by EPT. They even send an e-mail to the customer to ask him a 
> cleaning of his computer before requesting the re-opening of his e-mail 
> service.

I understand this. Again, *why* is this method superior? Any packet 
filter can do the same. A ISP can log connections to port 25 and calculate:

a. The number of connections made to port 25
b. The number of connections to different IP addresses to port 25
c. The overall traffic to port 25

If somebody misuses and sends bulk mail, the ISP will see it thanks to 
the packet filter. Advanced packet filters like Checkpoint-1 even can 
look into the payload of IP packets and reassemble them. Then, you can 
even log the SMTP headers. Even iptables can do this in a more 
rudimentary way. Why should one be forced to use the ISP's SMTP server? 
It is even a step backward if you consider that 'Caller ID' with SPF is 
the future.

> That's how it works right now, and I think it's not so bad. For sure, 
> it's not the silver-bullet against spams, but who has that silver bullet 

Sure, the silver-bullet *exists*. It is just not implemented on the mail 
servers around the world. The sender sends his mail over his mail 
provider's mail server using ASMTP (authenticated SMTP) or SMTP over SSL 
(Mozilla, Eudora, Outlook, ... support both methods). The reciepient 
recieves the mail from the sender's mail server and checks thanks to 
'Caller ID' if the mail has been sent throught the 'right' relay.

Today 'Caller ID' with SPF is optional. As soon as 60% of the mail 
servers support this, the other 40% will come into increased pressure to 
implement this as well, if the do not want to take the risk to be 
classified as spam.

The software is ready. Mail clients support everything which is 
necessary. Mail server software is also ready, just look in the header 
of the mails coming from this list. You will see that the mailing list 
server of linux.lu aleady supports SPF.

Greetings, Patrick Kaell