RE: [exim] support for domainkeys

David Brodbeck wrote:
>
..[snip]...
>
> That doesn't really accomplish anything, then. Let's say I'm a Comcast
> customer. (Not to pick on them; they're just a handy example.) I can
> still send all manner of spam through Comcast's MX servers, with any
> forged email address I want, and it'll be considered authorized because
> Comcast's MX has an SSL cert. It's even less effective than SPF; at
> least with SPF I can't forge a domain that has an SPF record that
> excludes Comcast's servers.

Not that all this reading has not been fun, but this is where I still
think that before we even worry about things such as SPF, DomainKeys, etc
we first tighten up what is valid and required information for a mail
server when connecting to another mail server (client submission is
different, but we have 587 for that). First things first, people always
get upset about this one, but all mail servers need to have proper
dns PTR records for the IP address that match the EHLO string given,
no this does not 'stop SPAM' per say, but at least we know that the IP
address and host name are easily traceable, I will never figure out why
people think that a mail server should be able to connect to another
mail server and give whatever information they want and have all be happy
with that, when EVERYONE knows better than this when it comes to websites
and other host information, in other words, if you want to connect to my
server, then the name that you give me should be able to be used, as given
to connect back to you, the PTR records are just added benifit that all
is in good working order for DNS, amongst other things. For those that
do use their ISP to send email, well the ISP needs to be restricting TCP
25 access out of thier networks, AOL does this, as do some others, and
good for them, at that point in time, it is the resposibility of the
individual ISP to either allow certain ranges of thier IP space to make
port 25 connections out, and it is their responsibility to ensure that
viruses/spam do not originate from thier client connections to thier
own relays. 'Bad' ISP's who let out too much, can then be either
blacklisted, or untrusted, you choose, but very easy to track. After
these small steps are implemented, then we can move on to all of the other
things such as SPF et. all. As to the hobiest SMTP admin, well, exactly
why do you need to be able to make direct connections to other servers
on TCP 25??? and I have never suggested that TCP 25 inbound should be
blocked, so you could still run your own mailservers.

--

--EAL--

--