11 msgReject unknown Sender address
10 msgPostfix and archiving
5 msg-o content_filter overrides main.cf ?
1 msgPostfix 2.4.3 and 2.3.11 available
8 msgSASL authentication via dovecot?
2 msgpostfix/sasl: sql_select option missing - wtf?
3 msgmax connection rate/count/limit issues.
1 msgrequeue mails
6 msgnothing in maillog
9 msglocal and remote storage for same user

Rejecting Invaliud Users - Useful Resource poin...
\ Terry Allen (31 May 2007)
. \ mouss (31 May 2007)
. . \ John Beaver (31 May 2007)
. . . \ mouss (31 May 2007)
. . . \ Terry Allen (1 Jun 2007)
. \ Rod Dorman (1 Jun 2007)
. . \ mouss (1 Jun 2007)

4 msgDistributing map files
5 msgrelay_recipient_maps for multiple destinations
13 msgauto-responders with postfix
6 msgMydestination with virtual domains
6 msgSplitting smtpd_proxy_filter in smtpd_recipient...
10 msgCan't Send to Sprint Messaging Users..
1 msgMAAWG meeting anyone?
2 msgbasic postfix 2.4.1 configuration for a simple ...
5 msgStrange persistant 'timeout after DATA' from ma...
Subject:Re: Rejecting Invaliud Users - Useful Resource pointers?
Group:Postfix-users
From:mouss
Date:31 May 2007


 
John Beaver wrote:
> mouss wrote:
>> Terry Allen wrote:
>>> Hi again,
>>> Our server is set for all domains to reject invalid users & I
>>> understand why rejecting non-existent users is correct - however, I
>>> am trying to demonstrate to a client why they should set their
>>> Exchange server up to reject non-existent users - can anyone point
>>> me towards an easy to understand resource I can show this client why
>>> they should reject non-existent addresses.
>>> The reason they are accepting invalid addresses is in case
>>> someone makes a mistake sending an email into the server - asking
>>> for a spam problem in my opinion. Many thanks for any pointers.
>>
>> If someone mistypes the address, he will get a bounce, fix the
>> address and send again. the recipient system should not try to guess
>> the recipient address. If you send mail to mouss, and
>> mistype it as nouss, you don't want the MTA or a person
>> to deliver the mail to nousse (which happens to exist).
>> practice has shown that guesses get wrong too often and cause more
>> problems than letting authors fix the issues once for all (html
>> automatic corrections, implemented in a browser-depende way, have
>> probably done too much harm than good). but I digress. anyway, the
>> client can do whatever he wants but he must not send a bounce unless
>> he can prove that the message was really sent by the sender. and if
>> he knows of a safe way to do that, then he has a large market for his
>> solution ;-p
>>
>> anyway, here are some links:
>> http://www.postfix.org/BACKSCATTER_README.html
>>
>> http://www.spamresource.com/2007/02/backscatter-what-is-it-how-do-i-stop-it.html
>>
>> http://secondwheel.googlepages.com/backscatter
>> http://en.wikipedia.org/wiki/Backscatter#Backscatter_of_email_spam
>> http://removals.tqmcube.com/index.php?x=&mod_id=2&id=13
>>
>> http://www.spamhaus.org/faq/answers.lasso?section=ISP%20Spam%20Issues#109
>>
>>
>> and you can get many resources by following the links on spamlinks.net:
>> http://spamlinks.net/prevent-secure-backscatter.htm
>
>
> Best answer above.
> Additional information. A company I worked for had this same
> thinking, however our Exchange was processing ~250k messages per day.
> We had multiple exchange servers handling the load internally. During
> a couple spam attacks (and joejobs, and email DOS), our load jumped to
> >1 million per day. Our systems crashed, the problem was due to the
> queue build-up of bounces to non-existent senders. I convinced them
> to do recipient validation AND isntalled a quick postfix system in
> front. Just recipient validation reduced our valid incoming mail to
> <100k per day from 250k. We got hit 2 days later, recieved 1.5
> million emails, 1 postfix server handled it. Saved us thousands in
> extra servers and storage that our IT group was planning to install to
> handle it all.
>
> Point being, not doing recipient validation make your system
> vulnerable to handling MUCH more traffic than needed.

and this is a very good argument that can be told to a CFO (or any non
techy mgmt guy): should we buy more hardware and more bandwidth because
some of our partners mistype addresses?

to add another point: while in the past the mistyping argument may have
been debatable (but even then, see my previous post), with the number of
junk mail today, there is no debate anymore.


© 2004-2008 readlist.com