3 Jul
2004
3 Jul
'04
1:14 a.m.
Hi,
.................................................
.................................................
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).
Provider mail servers are meant to be used to send your mail, whatever
the from email address is, because many mail providers _don't_ even have
smtp servers (at least in the past). I always send all my emails
through the service provider's smtp server I'm currently connected to.
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.
As long as the email is not digitally signed, you can never be sure who
sent you the email, and you shouldn't really rely on the outgoing mail
server.... (hint: check this email's mail server)
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.
In order that an email is send, data has to be exchanged between both
participating parties.... To my knowledge, if you spoof your ip address,
no data gets back to you, so you get no TCP connection to the server.
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.
Well, maybe in a 100 years..... ;)
Hope that they will warn you on time!
Greeting, Patrick Kaell
Thibaut
3 Jul
3 Jul
7:40 a.m.
New subject: Port 587 the solution?
Thibaut Britz wrote:
Well, maybe. But I hope not. The spam and the worms are just too
annoying. Something has to be done against it. And spammers get always
smarter. Now they use 'p0rn' and 'v1agra' to get around spam filters.
And if you filter too aggessively, there are also a certain percentage
of good mails which get deleted. A perfect spam filter just has not been
developed yet!
I think that generic mail relays are perfectly legitimate. But as we
have to give up some freedom for more security, they will have to go.
Just as the open relays had to go five years ago. As soon as nobody
accepted mails from open realys anymore, users of open relays had to
search for an alternative. This will also happen to the generic mail relays.
Greetings, Patrick Kaell
Greetings, Patrick
Provider mail servers are meant to be used to send
your mail, whatever
the from email address is, because many mail providers _don't_ even have
smtp servers (at least in the past). I always send all my emails
through the service provider's smtp server I'm currently connected to.
I used Deutsche Telekom's DSL service for 2 years. T-Online's relay
server never allower something like this. Only @t-online.de addresses
were allowed.
I studied the mail headers of the mails on this list yesterday. I was
*really* surprised how many of you actually send through your dialups
relay. I would never have thought this ;-)
As long as the email is not digitally signed, you can
never be sure who
sent you the email, and you shouldn't really rely on the outgoing mail
server.... (hint: check this email's mail server)
Also true. The mail signature is the best guarantee for this. But
remember: Not long ago you could send mails with anything in the From:
field. Spammers used From addresses where even the DNS part didn't
exist. Today such mails do not get delivered anymore. This is the state
of art today. I think that in future this checking will get more strict.
Recieving Mail servers will not only try to resolve the DNS part of the
From address but will also check if the mail actually has been relayed
by at least of one server which reverse resolves to the same DNS suffix.
It is not practical to do this with mail signatures.
In order that an email is send, data has to be
exchanged between both
participating parties.... To my knowledge, if you spoof your ip address,
no data gets back to you, so you get no TCP connection to the server.
You have to been on a backbone to do this. This is outside the
possibilities of the infected PCs and spammers.
This *will* effective be a *real* spam and worm killer!
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.
Well, maybe in a 100 years..... ;) 
24 Jul
24 Jul
8:34 p.m.
New subject: Port 587 the solution?
There is an IETF working group which aim is to work on those issues. As
mailing-lists are opened to anybody, you can follow their progress or
even give suggestions. More info on
http://ietf.org/html.charters/marid-charter.html
Description of Working Group:
It would be useful for those maintaining domains and networks
to be able to specify that individual hosts or nodes are authorized
to act as MTAs for messages sent from those domains or networks.
This working group will develop a DNS-based mechanism for
storing and distributing information associated with that
authorization.
The primary current use case for this facility is to allow recipient
MTAs to confirm that peer MTAs' actions are authorized by
specific domains or networks. This will help combat a certain
class of domain forgery common in spam. The solution chosen,
however, should be generally useful for others which might
check this authorization data. [...]
--
Brent Frère
Private e-mail: Brent(a)BFrere.net
Postal address: 5, rue de Mamer
L-8280 Kehlen
Grand-Duchy of Luxembourg
European Union
Mobile: +352-021/29.05.98
Fax: +352-26.30.05.96
Home: +352-307.341
URL: http://BFrere.net
3 Jul
3 Jul
7:54 a.m.
New subject: Port 587 the solution?
As long as the email is not digitally signed, you can
never be sure who
sent you the email, and you shouldn't really rely on the outgoing mail
server.... (hint: check this email's mail server)
Now what's the problem ;-) I looked at your mail header and learned the
following:
The recieving mail server (mxng06.kundenserver.de) got this mail from
tri-e2k.ethz.ch [129.132.112.23]. Now this mail server is not
responsible for yahoo.com. Conclusion: From address faked, mail
discarted (No, not yet. I read your mail, thanks to the freedoms we
still have).
If you want to be discarted today you can use the adress
thibritz(a)fuba.lu, because fuba.lu is not DNS resovable. 10 years ago we
didn't even have this freedom restriction ;-)
Greeting, Patrick Kaell
8002
days inactive
8023
days old
3 comments
3 participants
participants (3)
-
Brent Frère -
Patrick Kaell -
Thibaut Britz