The mailing list for listmasters using Sympa

[Patrick von der Hagen <address@concealed>]

Aumont - Comite Reseaux des Universites wrote:
> Patrick von der Hagen wrote:
[...]
> it but for sure, some development are needed. Check sympa-dev  archive, 
> thre is a thread about VERP  : 
> http://listes.cru.fr/sympa/arc/sympa-dev/2005-11/msg00003.html
Yes, I remember participating in that discussion. ;-)


> VERP on Sympa work is starting now.
That's great news. After I made exim append VERP-information to 
sympa-messages, I had a look at the sympa-bounce-processing code, but 
didn't dare to touch bounce-lib.pl myself, since I understand too little 
french. :-(
If you need alpha- or beta-tester, don't hesitate to ask...


[...]
> I agree that rejecting a message during the incomming SMTP session is 
> much more better then accept the message and create a bounce later. The 
> way Sympa accept or reject message is not simple and do not depend on 
> sender identity but also on any part of the message. This is done with 
> Sympa authorization scenario. Rules can be quite complex and use any 
> message property. So the best way to reject message during the incomming 
> SMTP session is to developt a MILTER interface to scenario so sendmail 
> could ask Sympa is the message is to be accepted or rejected during the 
> smtp session. Good idea : we will support thoses who start such 
> contribution :-)
My original idea was to have some tool to ask "would sender S to 
recipient R be rejected" and have that tool (script, daemon, whatever) 
answer either "certain rejection" or "don't know". Quite often the 
answer can be "don't know", but in many situations the answer might be 
"certain rejection". For example, if someone uses the 
send.private-scenario, this scenario could be verified with sender and 
recipient.

> > Integration with sendmail, postfix or exim should be quite easy, 
> > considering the interfaces provided by those MTAs. 
>
> Interface with sendmail is easy with Milter buit postfix does not 
> provide milter.
It doesn't have to be milter. Postfix privides its own policy-framework, 
but after a small scan of the documentation, it only provides 
Envelope-from and envelope-to, which is not necessarily the same 
information as seen by sympa. 
(http://www.postfix.org/SMTPD_POLICY_README.html)

But perhaps someone else here could imagine a solution that works with 
postfix?


> SPF is nice idea with a major problem : not compatible with forwarder 
> (forwarders transmit message without rewritting headers). SRS or a 
> alternative solution named "Responsible Submitter" tries to solve this 
> problem but they is a very strong issue the choosen solution must be 
> deployed everywhere before SPF can be really in use. Anyhow SPF is not a 
Yes, that's exactly the problem I've always seen. However, some people 
seem to be considering mail-forwarding to be some strange black art 
which should not be used in the first place... "breaking forwarding is 
no problem, just tell your users to stop forwarding and to access all 
their accounts using POP or IMAP...."
Personally, I just can't stand a system that expects everyone sending to 
you and everyone receiving from you to support an extension, otherwise 
the chain might brake. It's just to brittle....

> probleme for mailing list because mailing list are not forwarders but 
> remailers (remailers rewrite headers). SPF can also be a opportunity for 
I'd personally prefer "mailinglists don't have to be forwarders" or 
"mailinglists should not be forwarders", since I certainly know examples 
where mailinglists behave as forwarders. At least Listserv with the 
option "ietfheader" comes to my mind...
But it depends on the set of headers you refer to.

[...]
> Personally, i think DKIM is the biggest evolution in message service 
> since MIME was introduced.
Hmmm, I certainly consider DKIM to be much better than SPF/SRS, since it 
seems to be much more fault-tolerant when mail passes some host in the 
chain that provides no special support for DKIM. However, I'm not quite 
sure wheter the effect will actually be worth the trouble supporting it 
in the first place...

--
CU,
   Patrick.