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

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." 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. 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.

It's the RFCs and attitudes behind those RFCs that need modification.

(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.)

{^_^} Joanne

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

Relevant Pages

  • Re: UOL Anti spam is back, again...
    ... OTOH I don't clog up the Internet with messages that no-one wants. ... point out to you that procmail is probably the wrong place to bit bucket ... smtp server. ... you gain conformity with RFC's by rejecting it whereas ...
    (Fedora)
  • Re: Remove Internal Hops from Header
    ... Consider if you will an install that has an SMTP server running with in each department that forwards to the building / campus SMTP server that forwards to one corporate SMTP servers that then forward to the world. ... If you compare an internal SMTP structure to either an Exchange or GroupWise structure, you will quickly notice that SMTP will have additional Received: headers added by each SMTP server. ... When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header. ... Remember that RFCs are good guidelines to be followed with in reason. ...
    (comp.mail.sendmail)
  • Re: UOL Anti spam is back, again...
    ... smtp server. ... you gain conformity with RFC's by rejecting it whereas ... obviously rejecting when using fetchmail is a pointless option. ... waste a second of time greylisting it, scanning it for attachments, spam ...
    (Fedora)
  • Re: About those IMAP questions (was Re: Bogus From: Header ...)
    ... It sounds like the outgoing SMTP server you used is on one (or ... That's IF even adelphia will accept relayed messages, ... You want to get an email service provider that is ... You are going to get it *through the Internet*! ...
    (comp.mail.pine)
  • Re: About those IMAP questions (was Re: Bogus From: Header ...)
    ... It sounds like the outgoing SMTP server you used is on one block list. ... This is a problem that everyone is having these days and is one of the reasons that I recommended that you get a backup email service provider. ... You want to get an email service provider that is completely independent of any of your Internet *access* providers. ...
    (comp.mail.pine)