-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brad,
>> Do you really have a *policy* to accept messages that you will never
>> deliver, save them to disk, and then generate reject messages for
>> them?
>
> How could the MTA possibly know that the MLM would choose to reject
> those messages because the sender is not a subscriber? Or that the
> MLM might choose to hold those messages for moderation, because the
> sender is not a subscriber.
Better MTAs can do this.
> These are concepts that are totally beyond the scope of the MTA.
> There is nothing the MTA can do for you here.
It is much better to do this at the MTA level for the reasons I
previously outlined:
1) Do not accept stuff you will not deliver
2) Do not send rejection messages to spoofed senders
3) Do not annoy other postmasters (or more likely their automated
blacklists) by inundating them with junk
4) Do not be a backscatter source.
>> Or is that simply the way your MTA+MLM is configured by default?
>
> As far as the MTA is concerned, they are *ALL* configured this way --
> assuming that all the appropriate anti-spam and authorization checks
> have been passed, they detect that the recipient is a mailing list,
> then hand the message over to the MLM.
Of course they are all configured this way by default. Doesn't mean
they should stay this way.
>> Is
>> that *policy* really any different from your standpoint, from
>> rejecting
>> undeliverable messages during SMTP?
>
> The policy you are proposing is null and void, because the software
> in question is not physically capable of acting in the manner you
> suggest.
You have the sender and the recipient right at the beginning of the
SMTP transaction. Check a map to see if it's deliverable. Mailman
already maintains such a map. You just need some glue.
> Before chastising others so violently in public,
Uh, "violently"?
> you might do well to better learn how MTAs and MLMs really work, so
> that you can at least make accurate claims about what you believe that
> the software in question should be configured to do.
Check out:
http://www.postfix.org/SMTPD_POLICY_README.html
for instance. There are already policy servers written in Python, one
could use as a starting place. I'll bet a Python hacker could write a
mailman-subscriber-checker in very short order.
Surely other MTAs give admins a way to make decisions during SMTP as
well?
>> It would not be inconsistent with your current MLM policy. It is
>> simply a better mechanism for implementing it, a better MTA policy,
>> and
>> better netizenship to boot.
>
> Go back to basics, learn how MTAs and MLMs actually work.
>
> Then you are free to come back and tell us what you think the right
> solution is.
I think the right solution is to reject junk, instead of
accept-and-bounce. I think accept-and-bounce is a blight on the
internet, that lowers the quality and reputation of email. I think it
is a waste of resources.
- H
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFEB3fhOy/dHTCUq6oRAiBeAKD05nqBD2x6XM7aD+bvPsWmLRMnUQCgsciI
fz37JE3NOB4aXs/A5SpfnSQ=
=ra1X
-----END PGP SIGNATURE-----
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
