Re: tlug: Re: Test messages: Where's good?

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Scott" == Scott Perlman <perlman@example.com> writes:

    Scott> do we _really_ want an easy and helpfull way for spammers
    Scott> to verify that all their headers are perfect?

Who cares?  If it matters to their business, spammers will make it
right.  It's not hard if you're willing to pay an expert to do it
once, then spam ads for the program all over creation.  It's Joe
Newbie who needs an easy and helpful way to verify his config.

    Scott> oThe only saving grace you've ogt is reply goes to tcp/ip
    Scott> address by teh TCP/IP packet layer, but that may not be a
    Scott> valid mail recipient.  The case of people needing this are
    Scott> likely those behind firewalls and such where a
    Scott> straightforward configuration isn't available.

(1) People behind firewalls aren't going to be using a smarthost?
Insane.  There is absolutely no excuse for allowing direct outgoing
mail.  Fire the firewall admin.

(2) People behind firewalls have a professional to ask.  The firewall
admin.

(3) The firewall is a red herring; it does not affect the SMTP
transaction at all, unless it goes via a smarthost, in which case Joe
Newbie only needs to talk to the smarthost admin.  So there's no
reason to suppose that people behind firewalls would have more
problems.

There will be plenty of people not behind firewalls who want to use
such a service.  (Still hypothetical.)

>>>>> "Chris" == Chris Sekiya <chris@example.com> writes:

    Chris> On Tue, 26 Jan 1999, Stephen J. Turnbull wrote:

    >> Any message body goes to /dev/hell, reply goes to the IP
    >> address provided by the TCP/IP layer.

    Chris> Think about that second part for a minute.

I did.  (1) If you're on the net temporarily, just make sure you hang
around long enough to get the reply.  Don't forget to uncomment smtp
in inetd.conf.  (2) Firewalls are a red herring.  (3) IP spoofing is
an awful lot of effort to go to for so little effect.  OK, we don't
accept more than 1 connect a minute, limit 5/day (or whatever length
of time we feel like keeping the cache) from a given IP address.

Should I think for another minute?  Hints?

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
-------------------------------------------------------------------
Next Technical Meeting: February 13 (Sat), 12:30 place: Temple Univ.
** presentation: XEmacs, by Steven Baur and Martin Buchholz
Next Nomikai: March 19 (Fri), 19:30   Tengu TokyoEkiMae 03-3275-3691
-------------------------------------------------------------------
more info: http://tlug.linux.or.jp                     Sponsor: PHT