On 8/17/2014 7:37 AM, Linda Walsh wrote:
Karsten Br���������������������������������� wrote:
Similarly, your scripts do not reject messages, but choose not to fetch
them.
===
No... fetchmail fetches them, "sendmail" rejects them because they
don't have a resolvable domain. My sorting and spamassassin scripts
get called after the email makes it through sendmail. My scripts don't
see the email.
Pragmatic solution: If you insist on your scripts to not fetch those
spam messages (which have been accepted by the MX, mind you), automate
the "manual download and delete stage", which frankly only exists due to
your choice of not downloading them in the first place. Make your
scripts delete, instead of skipping over them.
----
'fetchmail', that I know of, isn't able to tell if a sending domain is
invalid
until it has fetched the email (that I know of).
Fetchmail has no other way of doing it, how would it be able to
determine if a sending domain is valid or not until it has read in the
email message?
Fetchmail ATTEMPTS to determine the original envelope senders address
when it's processing mail, but can't always do it.
fetchmail tries to send
the email
to me via sendmail, which doesn't accept the email because it is
invalid. Unfortunately, my ISP doesn't use sendmail or it would reject
such emails by
default.
No wonder you are frustrated. You are like the person who learned to
play gold by watching TV - you have so many misconceptions and wrong
ideas of how to play that it would literally take LONGER to teach you to
unlearn all of this and learn the proper way to do it, than to start
with someone who had never played golf.
Your going to need to re-learn much of what you think you know before
you can get what you want. Sorry to be harsh but you have been
basically lied to for so long - probably by your former ISP - that
now your going to have to go through a lot of pain to get rid of
all of those lies.
email simply does not work the way you think it does.
For starters, anyone configuring Fetchmail to pass mail to Sendmail
needs to disable all SMTP checks in Sendmail. Why? Because they are
utterly useless. The purpose of these SMTP checks for valid domains and
suchlike is that when Mr. Spammer opens an SMTP connection to you to
spam, if you can detect that it's SPAM before the SMTP transaction is
accepted, then you can deny receipt - and if the spam is relay spam
from a broken-into mailserver that the spammer has hijacked, those
bounced mails will clog up that mailserver, informing the server
admin there's a problem and getting the open relay shut down. If
the deny is directly back to the spammers server then the spammers
server is slowed down, and the spammer has an incentive to remove your
email address from his list.
Once the mail is successfully delivered by the spammer to the server
that fetchmail is pulling mail from, then none of this can happen - you
have effectively told the spammer "yes you have a valid victim address"
You need to setup your sendmail so that it accepts everything fetchmail
gives it. You can then post-process with SpamAssassin to filter for
spam. And that is ALL you can do to block spam.
The ENTIRE focus on "spamfiltering" at the SMTP transaction level is to
prevent the acceptance of SPAM before the SMTP transaction phase is
completed.
But, in order to content filter - to see what is actually inside the
mail message - you MUST complete the SMTP transaction phase.
So it is like Internet dating.
You can view the person's profile all you want, they can have the best
looking profile, the prettiest picture, the best reviews - but until the
clothes come off, you don't know what you have.
Be liberal in what you accept, strict in what you send. In particular,
later stages simply must not be less liberal than early stages.
----
In this case, I don't even want the invalid email passed on to me. I don't
want to accept spam. The first defense is to have the MX reject
non-conforming
email.
Your MX has accepted the message.
My ISP's MX has accepted it, because it doesn't do domain checking. My
machine's
MX rejects it so fetchmail keeps trying to deliver it.
While I *could* figure out how to hack sendmail to not reject the
message, my
preference would be to get the ISP to act responsibly and reject emails
without
a valid return domainname. It's standard in sendmail, rejection of such
email is called for in the RFC's. The choice to not follow RFC's allows
spam that would normally be rejected, through to my system which does
follow
the standards and rejects it -- so it stays in the "download queue" for my
domain.
The SMTP RFCs do not require rejection of email with a bogus senders
domain in the header address.
At that point, there is absolutely no
way to not accept, reject it later. You can classify, which you use SA
for (I guess, given you posting here). You can filter or even delete
based on classification, or other criteria.
The MX shouldn't accept it based on RFC standards. When I asked for it to
be blocked, I was first asked for the name of the "offending domain" and
told I could blacklist the domain by adding it to a list with their
web-client.
I asked for a scriptable way to do this after a domain lookup, they said
they no longer offer scripted solutions as the ISP I signed up with (who
they bought) did.
There is a reason they bought that ISP. That ISP was not making money.
This ISP is making money, at least enough to be able to afford to buy
that other ISP.
You may have loved your old ISP because your old ISP was clueless and
it was a situation of the blind leading the blind. So your old ISP
allowed you to keep your misconceptions of how things work and that
allowed you to build those small misconceptions of how things work into
these larger misconceptions of how things work.
So now your old ISP couldn't survive and died - and you have this huge
misunderstanding of how things work and your assumptions are being
smashed against the hard rocks of reality of how things actually work.
The only response my ISP will give is to turn on their spam
filtering. I tried that. In about a 2 hour time frame, over 400
messages were
blocked as spam. Of those less than 10 were actually spam, the rest
were from various lists.
So having them censoring my incoming mail isn't gonna work, but
neither will
the reject the obvious invalid domain email.
I can't believe that they insist on forwarding SPAM to their users
even though they know it is invalid and is spam.
There is no censoring.
When I complained about the problem I found that "recommended filter
rules" had
been activated on my account. In the couple of days they were active
about 80% of
the messages they caught were not spam -- and some of the bad domains
still got
passed through.
There is no forwarding.
It comes in their MX, and is forwarded to their users.
Any ideas on how to get a cheapo-doesn't want to support anything ISP
to start blocking all the garbage the pass on?
Change ISP. You decided for them to run your MX.
----
I didn't decide for them, I inherited them when they bought out the
competition
to supply lower quality service for the same price.
It is your choice to aim for a cheapo service (your words).
It wasn't when I signed up. Cost $100 extra/month. Now only $30
extra/month that I don't host the domain with them.
If you're
unhappy with the service, take your business elsewhere. Better service
doesn't necessarily mean more expensive, but you might need to shell out
a few bucks for the service you want.
----
I already am... my ISP (cable company) doesn't have the services I want
for mail
hosting. I went to another company for that, who was bought out some
times ago, with
the new company dropping quality as time goes on. In this case, I wanted to
try to push back against them accepting the illegal (not to spec) spam
and forwarding
it to their customers in the first place.
There are many "compromised" solutions that are available. Certainly
such choices are
not my first, which was why I posted here to see if anyone else had any
experience
with getting an irresponsible ISP to reject non-compliant email, and
barring that,
maybe getting offered better choices from the experience of the people
on this list.
My mail business - http://www.portlandiacloudservices.com - offers
FreeBSD shell accounts. You could do all the scripting you wanted
there. But for what I charge for those I expect people who get these
accounts to know what they are doing and ask on public forums for
assistance. If your OK with that, go to the site, read it, and send an
email to the address on the site.
Ted
Cheers!
'^/
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
