It will be a cold day in hell before I use xtras SMTP server, every time I
have tried the comboniation of it having zero DNS entries relevent to the
domain name used in the from address, and its presence in some spam list has
resulted in at least one email going out being tagged as spam.
Using my hosts smtp which has the reverse lookup all set up (no SPF yet -
been too lazy to do that) and the mail gets thru without being tagged as
spam.
Happened for someone that I work with as well, because a lot of the content
of there newsletters gets picked up by the words in it.
The solution is for recipients to refuse mail based on it being a dynamic
IP, and having the reverse of the IP having nothing to do with the domain
name in question. That seems to work very well indeed. For shared servers
without there own IP there is SPF records but obviously when other people
have access to relay thru that same server you want to take it carefully.
Ideally all end user SMTP would require authentication, but that's not gonna
happen when there are broken AV packages around that still trap smtp when
they don't support secure or authenticated smtp.
-----Original Message-----
From: owner-***@unixathome.org [mailto:owner-***@unixathome.org] On Behalf
Of Mark Foster
Sent: Tuesday, April 04, 2006 9:17 AM
To: Brian Wrigley
Cc: Mark Foster; ***@lists.unixathome.org
Subject: Re: Xtra to close 25/TCP Outbound...
G'day Brian. Response inline.
Post by Brian WrigleyM> This is unrealistic in the day and age we live in.
It seems to have been realisitic enough up until now. On fact, the
last couple of years I've seen a reduction in the amount of spam I
receive, not an increase, in all mail services except Xtra. In Xtra's
case, I think it's just policy - they want to sell me a filtering
service so they send me spam now that they used to delete. Most of
it's not addressed to me but to randomly generated addresses similar
to mine.
I've been running my own MX for a rather long time - I've lost count, but at
least 4 years. Spam volumes have gone _up_ in general. Note that I don't
process inbound mail via Xtra or any other ISP... I telehouse my own system.
Post by Brian WrigleyPost by Mark FosterNote we're only talking about the blocking of access to port 25 here.
The amount of junk that propogates onto the internet from client-side
machines via direct SMTP connection on port 25 is as you're probably
aware, phenomonal. (I can post some stats from the blakjak.net mx as
to how much stuff is caught by the sorbs dynamic-ip blocklist i'm
using, if required.).
How much genuine mail do you get that way (ie from individual machines
or non-isp servers)?
Genuine email from home-connections? None. Home users who try to do their
own MX lookups tend to find their mail gets rejected for exactly the reasons
described. And, even if you had the power to influence local ISPs, this
doesn't change the situation when trying to send email overseas, etc. If
you want your mail to be accepted you need to adhere to accepted best
practise... or take your chances.
Post by Brian WrigleyPost by Mark FosterIf you want to pop your mail from anywhere, Xtra are not blocking this.
If you want to send mail, theyre requiring that you use smtp.xtra.co.nz.
Given that SMTP is not tied to the place you're getting service from,
this is not a hindrance.
No? hehe, scroll down to this entry: http://www.blakjak.net/node/478
See why I don't want to be limited to using Xtra's smtp server?
All ISPs have this issue from time to time - welcome to the world of SMTP.
Its a 'best effort, FIFO' service. Anyone who relies on email for
time-critical notification of anything needs to be aware of this fact.
Thing is, I can easily work around the SMTP limitation by using my webmail
system as-required, even if I can't SMTP directly into my own host, thus
bypassing Xtra.
Also note this same logic - and similar problems - applied when I used other
ISPs... and i've used at least a couple of others in the last 10 years.
Post by Brian WrigleyPost by Mark FosterOh, and I read on newsgroups a few moments ago that Gmails pop3/smtp
service don't use conventional ports, so youd remain unaffected
anyway for that service.
Correct. GMail uses a secure connection on different port numbers, so
GMail will not be affected. But the Yahoo and the web host's servers
are on the conventional ports. It's totally reasonable and legitimate
for me to want to use those services, and unreasonable for Xtra to
block my use of them.
Incorrect. Convention dictates that regardless of where you get your mail
_from_ you should use your ISP smtp for sending. Services which advertise
the fact that their own SMTP server should be used as a preference - well,
given appropriate means of preventing abusive SMTP relay (smtp-after-pop or
Auth'd SMTP) this is technically OK, but unrealistic in this world of
viruses and drones. We need to adapt, or face the fact that email as we know
it is doomed.
Post by Brian WrigleyPost by Mark FosterBut you should be using your mail providers service for pop3 or imap only.
Your ISP should be your SMTP service provider.
I beg to disagree with these particular "shoulds". There's no reason
why one's ISP need be one's only provider of SMTP services.
Plenty of reasons - tied to whole concept of SMTP being unauthenticated, and
therefore the 'authentication' of using your ISPs SMTP is in the ACLs
applied. Noone should expect to be able to do direct MX lookup from a
residential grade dynamic-IP host without also expecting to see their mail
get rejected in many cases, or marked as spam in others. *shrug*.
Note that idealistically I agree with you, but your perspective doesn't
really reflect the internet-at-large as of 2006. (or earlier.)
Post by Brian WrigleyPost by Mark FosterAnd as a dynamic-ip
(presumably) home-user you shouldn't be doing your own MX lookups anyway.
Tends to get you scored as a spammer or drone straight up.
Dynamic IP, yes. Although it can stay the same for months sometimes.
And as far as I know I'm not looking up MX records personally - unless
Outlook Express, or the router, or the Cold Fusion development server,
do it behind the scenes for some reason. What is an MX record for and
when does it need to be accessed? (if it's too complex to explain in a
nutshell, just say so and I'll look it up)
The nutshell version of what-is-an-MX. However let me first point out that
the protocol used by ISPs to deliver email between themselves is exactly the
same as that you use as an ISP client to send email out using Outlook
(etc)...
So the what-is-an-MX:
- MX record appears in the DNS zone file for any given domain.
- When a mail server wishes to deliver an email it needs to know where the
destination mail server for a given domain.... so an MX query is issued:
;; QUESTION SECTION (1 record)
blakjak.net. IN MX
;; ANSWER SECTION (1 record)
blakjak.net. 2h IN MX 5 mx.blakjak.net
So in a similar way to the query 'i want to get to www.google.com, what is
its IP?' as asked by your web browser (an A record query), a mail platform
asks for the 'mx' - the mail server. (Can be multiple responses; the number
denotes a priority where the lower the number, the higher the precedence).
So in the above situation a further query - 'what is the IP of
mx.blakjak.net' is directed into the DNS - an answer supplied - and the mail
server can then go connect to it on port 25.
At home, your mail software doesn't do MX lookups. Instead you specify an
SMTP host. This is a 'fixed' address... eg, regardless of where you're
sending your email, you send it to this single host. SMTP service is
provided your ISP as a component of your internet account.
The ISPs SMTP server goes through the above lookup process and delivers the
mail on your behalf.
So from home, you're either:
- Sending mail to your ISPs SMTP server, to deliver on your behalf, or
- Sending mail directly to the MX record of the domain youre sending to, or
- Sending mail to a third party mail provider (ala Yahoo) who do what your
ISP does.
What Xtra are going to do is block the second option - your ability to do
direct MX lookups and then connect to them for SMTP purposes. It'll also
block the third option (use of a third party). The first option, which 99%
of internet users will be using anyway, remains available.
Post by Brian WrigleyPost by Mark FosterIf its outbound only, eg, to mitigate the affects of virus infections
and spam relay by drones, etc, then I support it fully.
That's what they're trying to achieve, of course - blocking zombies
sending spam from their own smtp engines by connecting to the smtp
server at each domain they want to send mail to. Blocking the port
casts the net wider than this though.
Given the above how do you discriminate?
Viruses use the same MX lookup process as a mail server does... the same
process you'd be using in the second example above. Theres no way to block
one and not the other.
If you look at any given mail server and put the number of 'legit'
messages received direct-from-sender next to the number of worms, viruses
and spam messages, .... the numbers speak for themselves.
Spam is no longer the fault of open mail relays - they rarely happen. Its
all about the infected-boxen, now.
Post by Brian WrigleyPost by Mark Fosterthe NBR article which Kerry mentioned (which i'd already located...
snap!) that has some useful comment. Still looking to see how the
exceptions would be handled - theyre offering exceptions at no cost
it seems - and still wanting to confirm that the affects would be
outbound-only.
When the time gets closer I'll ask them for an exemption and see how
they handle it.
I'll be doing the same, in all likelyhood.
Mark.
--
This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ, and various documents.
To unsubscribe: send mail to ***@lists.unixathome.org with
"unsubscribe adsl" in the body of the message
--
This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ,
and various documents.
To unsubscribe: send mail to ***@lists.unixathome.org
with "unsubscribe adsl" in the body of the message