Re: UOL Anti spam is back, again...

On Wed, 2006-03-08 at 13:11 -0800, jdow wrote:
From: "Craig White" <craigwhite@xxxxxxxxxxx>

On Wed, 2006-03-08 at 18:07 +0000, Anne Wilson wrote:
On Wednesday 08 March 2006 17:23, Craig White wrote:

OTOH I don't clog up the Internet with messages that no-one wants.

----
and sell it as a premium service on top of that too! ;-)

Slight misunderstanding of what I was saying ;-)

seriously though, I know you run your own smtp server and I am trying to
point out to you that procmail is probably the wrong place to bit bucket
stuff like this.

AIUI, if you reject the message it is returned to sender, thus causing still
more Internet traffic. There has to be a very good reason to justify that.
----
actually no, it's less Internet traffic (bandwidth) because:

- you reject an email by smtpd restrictions and thus it is never sent.
- you have every reason in this case to believe that it is their
(uol.com.br) smtp server (and not a relay agent).

In addition, you gain conformity with RFC's by rejecting it whereas
accepting it and then tossing it into bit bucket doesn't conform to
RFC's
----

The better place is to reject it at the smtp server and thus, you won't
have to run it through spamassassin/anti-virus/procmail etc. and also,
by rejecting it at smtp server, at least the sender has a chance to find
out what happened to the email, whereas when you bit bucket it, very few
clues are left behind.

There is one flaw in your logic - the people that sign up for this service
have been led to understand that it is a 'good thing', so they are not going
to take much notice. If you think how many of those things have been
rejected by list readers - do you see any change in the behaviour of
uol.com.br? None at all. Is the person who signed up for the service taking
any notice of the rejections and changing his provider? Obviously not, as
this has been going on for a long time.
----
I am not totally certain what motivated people to sign up for this
service and can only guess that it is for spam control and in a sense,
it is likely achieving that end.

There is no flaw to my logic because if you accept an email and then
direct it to bit bucket, neither sender nor recipient are ever gonna
know what happened to it and maillog will show it was received but no
more and procmail log ***might*** show what happened to it ***if*** the
user has directed procmail to log.

So much effort to get rid of email that should simply be rejected at the
outset by your SMTP server.
----

Each to his own, Craig. We all do what we think best.
----
Indeed - I thought it might be an opportunity to demonstrate a better
way of dealing with these things when you control the SMTP server. If
you aren't going to employ the better SMTP logistical approaches, why
bother running your own SMTP server?

Craig, sue me. I am not going to REJECT for multiple reasons, one of which
is "howinell do you do this via fetchmail."
----
obviously rejecting when using fetchmail is a pointless option. ;-) I
suffer from the same problem at my home mail because I too use fetchmail
but my clients don't and it is very much an option (to reject) and in
fact, it is a highly desirable option, as is greylisting.
----
Another reason is ideological.
The RFCs are broken in this regard. They were generated in a world that had
not gone as mad as it has become now. The only sane way to handle these
cretinous C/R messages is tossing them out the window.
----
when your vehicle for receiving email is fetchmail, you are correct
----
I categorically
refuse to deal with them. And specific people who use them end up in my
/dev/nul list. I *specifically* do NOT want to see their trash mail. And
no RFC is gonna force me to see them while I am alive.
----
the beauty of rejecting is that it does generally meet RFC's - it's
polite, it's proper, it's as efficient as it gets because you don't
waste a second of time greylisting it, scanning it for attachments, spam
pattern matching, end user delivery and rulesets
----

It's the RFCs and attitudes behind those RFCs that need modification.
----
not my agenda
----

(I bet you do not approve of spam filters that simply /dev/null very obvious
spam, too. It's your prerogative. But I think such an action is stupid if
you are not interested in keeping spam statistics.)
----
you haven't see me list my statistics on spamassassin list so that
should be a clue that I am not overly concerned with them. If you use
greylisting, you've scraped such a high percentage of spam off the top
that the statistics look skewed compared to someone who isn't using
greylisting so the inevitable comparisons seem meaningless.

It was amusing to see Rene Russo and Mel Gibson compare scars in Lethal
Weapon (?) but not truly indicative of who was actually tougher...I
mean, did she eat the dog biscuits?

Rulesets that send mail to bit bucket should be very judiciously used
but you have to make your own peace and I have to make mine. The point I
was trying to make - is that if you run your own SMTP server, why not
get the most effectiveness out of it and reject mails early in the
process rather than after all the work has been done? Your answer, is
you don't have the option because the SMTP server for your mail has
already accepted them and you use fetchmail to get access to them.

Craig

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Relevant Pages

  • Re: Fetchmail not flushing mails with non-resolvable domains
    ... Just realised though (through running Fetchmail at the console rather ... The bulk of this uncollected mail is likely spam, but how can I have it ... That's an SMTP error message, not a fetchmail error as such. ... message from the SMTP server, indicating that it may be fixed later. ...
    (uk.comp.os.linux)
  • Re: Exchange Hijacked
    ... >Lot's of spammers use domains that either have no inbound SMTP server, ... find the compromised user account ... Thats a lot of spam and a lot of email addresses, ... > Turn off the ability for authenticated users to realy and see what ...
    (microsoft.public.exchange.admin)
  • Re: SMTP not relaying all emails
    ... The emails are flagged due to having the SMTP Server in another domain, ... If it is spam blocked, the receiver can set it so it allows the GoDaddy ... ADODB.Fields oFields; ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: How long does read(2) wait before an EAGAIN is thrown?
    ... The idea being that if the server is known to be a pure spam source, ... It may also delay/block the connection just because the IP address is ... The idea is to slow the sender down a bit, ... I'm connecting to the Exim SMTP server on my local Linux box, ...
    (comp.unix.programmer)
  • Re: Is this some type of hacking or exploit attempt?
    ... my firewall, within between 15 minutes and sometimes a couple of hours ... It looks like you are rejecting mail when the connecting IP address ... the spam is spam rather than making the spam stop, ... if they are essentially nothing more than a front for spammers. ...
    (comp.mail.sendmail)
Loading