Re: Overview of rcpt checkers

[Juerd Waalboer]

James Turnbull skribis 2007-12-07 11:30 (+1100):
> This would make a great addition to the Wiki - http://wiki.qpsmtpd.org

Agreed in principble, but I'm planning to release this as a document on
CPAN, and don't want to maintain two versions. A link to the page on
CPAN, when it's there, is of course very much possible.

I'm going to email all the authors, as far as I can find their
addresses, so they have a chance to respond to my critique. I'm not
going to wait longer than a few days though, because I want to go ahead
and write an article about replacing qmail-smtpd with qpsmtpd, and want
the document ready by then.

On IRC I've already gotten way too many "a solution already exists, stop
wasting our time with your announcement" responses, so I extended my
notes to a readable document to show whoever wants to read it, that a
sufficiently compliant solution did not pre-exist.
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

Re: Overview of rcpt checkers

[Juerd Waalboer]

Robin Bowes skribis 2007-12-07  0:24 (+):
> You forgot my plugin:
> http://robinbowes.com/projects/check_validrcptto_cdb

Sorry. Will add to the next version.
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

Re: Overview of rcpt checkers

[James Turnbull]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Juerd Waalboer wrote:
> For your convenience,
> 

This would make a great addition to the Wiki - http://wiki.qpsmtpd.org

regards

James Turnbull

- --
Author of:
- - Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
- - Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
- - Hardening Linux
(http://www.amazon.com/gp/product/159059/)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHWJQ89hTGvAxC30ARAoMSAKCx/mcS9AkFdr0mRxBkwiVs4kZc5wCglhjM
xBhZo0/Cea9Qb2qXIQ+OBVk=
=Yv6o
-END PGP SIGNATURE-

Re: Overview of rcpt checkers

[Robin Bowes]

You forgot my plugin:

http://robinbowes.com/projects/check_validrcptto_cdb

R.

Overview of rcpt checkers

[Juerd Waalboer]

For your convenience,

   +--includes build script
Pregenerated list  | +--script uses qmail-local logic
   | | +--supports users/assign
   | | | +--detects local users/getpw
   | | | | +--.qmail-default/catch-all
   | | | | | +--.qmail-ext-default
   | | | | | | +--vpopmail
   | | | | | | | +--ezmlm
   | | | | | | | | +--bouncesaying
   | | | | | | | | | +-- db/cdb files
  for lang V V V V V V V V V V
Solution:
goodrcpttoq-s CY n n Y Y n x n x Y
check_goodrcptto  qp  perl n x x x Y n x x x n
validrcptto   q-s Cn x x x Y n x x x n
validrcptto.cdb   q-s CY Y Y Y Y n Y n n Y
magic-smtpd builtin   -   Cn x x x Y n x x x Y

   +--uses qmail-local logic
Dynamic (real time) checking   | +--queries daemon
   | | +--supports users/assign
   | | | +--supports local users(getpw)
   | | | | +--.qmail-default
   | | | | | +--.qmail-ext-default
   | | | | | | +--vpopmail
   | | | | | | | +--ezmlm
   | | | | | | | | +--bouncesaying
   | | | | | | | | | +-- cdb files
  for lang V V V V V V V V V V
Solution:
qmail-realrcptto  q-s CY n Y P Y Y n I n Y
check_deliveryqp  perl Y n Y Y Y P Y ? n Y
vpopmail_check_recipient  spp sh   n n n n P P Y Y n x
local_check_recipient spp sh   n n n P Y P n n n N
check_recipient   spp perl n n P P Y P n I n N
vpopmail-check-user   m-s sh   n n n n n n Y n n x
qmail-verify  q-s CY Y Y Y Y Y n I n Y
check_qmail_deliverable   qp  perl Y Y Y Y Y Y Y I P N

   q-s is qmail-smtpd, qp is qpsmtpd, spp is qmail-spp, m-s is magic-smtpd

   Y = yes, n = no, I = implied by .qmail-ext-default, P = partial, x =
   not applicable

I will release a more verbose document with a future version of
Qmail::Deliverable, and this comparison document will be called
Qmail::Deliverable::Comparison
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

Re: PLUGIN FOR E-MAIL TO SMS

[Juerd Waalboer]

Luis Villarino skribis 2007-12-06 10:23 (-0800):
> the problem is that I use this software http://www.successware21.com/ and I
> can go inside and make any modification

I think you meant "can't".

Just write a wrapper for it: a simple script that reads in a message,
splits it into multiple parts, and then calls your software for each
part.

A very simple dot-qmail script could do this:

#!/usr/bin/perl -w
use strict;

# ignore headers
1 until readline(*STDIN) =~ /^$/;

# slurp message
undef $/;
my $message = readline(*STDIN);

# split message
my @parts = unpack '(a160)*', $message;

# send parts
system '/usr/bin/program-that-sends-sms', $_ for @parts;

Note that I haven't looked at successware21.com, and that this example
code is untested.

> Mi idea is in the server make the process or just save the message in a
> mysql database and create another script that make the split process
> and the email server will be just for this application

Grand overkill if you ask me. But if this is what you want, what exactly
is your question to us? Where did you get stuck while building this?
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

Re: PLUGIN FOR E-MAIL TO SMS

[Juerd Waalboer]

Luis Villarino skribis 2007-12-06 10:16 (-0800):
> I need a plugin that split one email in many and send the email again . Why
> I need this because the email will be an sms message and this messages has
> size restriction

I humbly suggest that put this logic with the part that sends the SMS,
not in the SMTP daemon. It will be easier to make because you won't have
to deal with all the subtleties of rfc2822 and SMTP, and easier to
maintain because of the same, and because you won't have to separately
specify the recipients that require such splitting.
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

PLUGIN FOR E-MAIL TO SMS

[Luis Villarino]

Hi:

I need a plugin that split one email in many and send the email again . Why
I need this because the email will be an sms message and this messages has
size restriction

or

I need a plugin that store all the email in mysql database

thanks
Luis

-- 
IT Consultant
www.LasVegasWH.com

Re: IDN support in SMTP?!

[Ask Bjørn Hansen]

On Dec 6, 2007, at 5:51, Peter J. Holzer wrote:

I did not want a proposal for IDN. I wanted one for a generalization  
of the parser so

that plugins can be used to change the acceptable syntax.


You can already do plugins that intercept the default parsing -- but I  
take it you mean making Qpsmtpd::Address pluggable somehow?


--
http://develooper.com/ - http://askask.com/

Re: Rewriting the body

[Juerd Waalboer]

Peter J. Holzer skribis 2007-12-06 16:23 (+0100):
> > So it would make sense to rewrite bodies, and since qpsmtpd is at the
> > gate already, I'd like to put the solution there. Nothing fancy, but it
> > would need to support simple multipart messages.
> > I couldn't find documentation about rewriting the body, and a quick look
> > at the plugins showed no plugin that already does something like this.
> > Is changing the message supported at all? Has anyone actually done it
> > yet?
> My old qpsmtpd tutorial
> (http://www.hjp.at/projekte/qpsmtpd/tutorial.rxml) contains a plugin
> which appends a signature to each message. So at least appending to a
> message works. I do think that you can rewrite the whole body by simply
> seeking to to the start of the body before calling
> $transaction->body_write. Ah yes, $transaction->body_resetpos should do
> the trick. Look in Qpsmstpd::Transaction for details.

Thank you. Especially for the tutorial which has a very nice example
indeed.
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

Re: IDN support in SMTP?!

[Guy Hulbert]

On Thu, 2007-12-06 at 14:51 +0100, Peter J. Holzer wrote:
> 1) The syntax is baroque. Moving the parser from the core to a plugin
>would make the core cleaner.

Removing everything from the core would make it really clean.

I think a clear design document which defines the core/plugin interface
and a roadmap towards a freeze of this interface is essential to ever
reaching 1.0 and I think that reaching 1.0 should have some priority.

I do not care about the details but a having a stable target is a
critical goal.  There are many examples of projects which are either
stalled or limping along because the project goal is unclear or too
large.

Change the syntax in the core or first make a clear distinction between
what is core and what is pluggable.  You can still have a transitional
period since qpsmtpd is not at 1.0 yet.  Perl6 is promising that you can
have your own grammar so making the syntax a plugin will be unnecessary
as soon as perl6 comes out ;-).

I would find it much easier to commit more time to qpsmtpd, if I had a
little more certainty that the project will be successful.  My
definition of "success" is that people can easily use it without
subscribing to this list :-).

-- 
--gh

Re: IDN support in SMTP?!

[Guy Hulbert]

On Thu, 2007-12-06 at 14:51 +0100, Peter J. Holzer wrote:
> > 1. Don't do anything until there is an SMTP RFC which covers IDN.
> 
> You misunderstood what I wanted a proposal for. I did not want a
> proposal for IDN. I wanted one for a generalization of the parser so
> that plugins can be used to change the acceptable syntax.

Not really.  I object to both things ;-)  However, I will now read the
rest of your explanation on the second issue.  I doubt that I object
enough to make it worth another post. 

IDN is much worse.

Please see my follow-up under the topic eai[*].  Work on SMTP is barely
getting started but it appears that IDN and RFC 3490 are a collossal
mistake (imo, not at all h) and should be avoided except where
necessary.  I think it would be far better to start with the new draft
RFCs then to blindly implement RFC 3490.

There seems to be an ESMTP extension (possibly only proposed) for
allowing UTF-8 but this may just be for headers.  This is referenced in
the new eai drafts.

I don't know whether RFC 3490 must be used in the envelope.  Probably.
That will be extremely annoying as you will have to translate addresses
to compare.

I believe that the ACE (see below) adopted was probably DUDE (which
provides a one-to-one mapping to UTF-8, iirc -- some of the other
encodings proposed did not, i think).  That should be clear from reading
3490.

Bernstein demonstrated that in 2001 UTF-8 already worked in the envelope
for djbdns and qmail transparently and that trivial patches were
required for bind and sendmail.  Microsoft applications were already
able to use UTF-8.  Only after RFC 3490 was adopted, did microsoft (and
some others) change their apps.  So everything except DNS follows
RFC2277 (i may have the number wrong -- from memory it's all 2s and 7s),
which requires UTF-8 on the wire.  Hopefully RFC 3490 has some allowance
for a transition to UTF-8 ... some of the IDN WG suggested that
replacing DNS was a better idea.

See below for further amusement.

[*] Subject: Email Address Internationalization

--gh

Summary of the IDN WG email list.
-

First of all, a few people on the IDN working group, including the
chair, insisted that an ACE solution (ASCII Character-set Encoding -- or
something like that) was absolutely required because of compatibility
with existing 7-bit applications.  In particular BIND and SENDMAIL.

Bernstein argued that there were existing trivial patches or workarounds
for BIND and SENDMAIL which would suffice.  He proposed mandating these
fixes with a reasonable time period allowed for transition.

The difference between these two stands is that the first avoids short
term pain for many sysadmins while the second avoids long term pain for
all programmers writing network apps (perhaps a smaller group than the
first).  IETF has a tradition of taking the first path and Bernstein is
quite vehement regarding the long term adverse consequences.

He also pointed to RFC 2277, which required all future protocols to
support UTF-8 on the wire.

As usual, Bernstein was accused of ad-hominem attacks ... I don't agree
with this assessment but I do agree that he is not particularly
diplomatic.  He did lose it completely at one point and used all caps
for 3 sentences.

He asked several times for a vote that there was a concensus that UTF-8
would be adopted eventually but his opponents claimed that he must write
an RFC proposal first and he never did that, as far as I can tell.  I
don't know if this is considered in 3490 ... it should, at least,
reference 2277 and justify non-adherence ... but I don't know until I
read it and I may not bother.

Re: Rewriting the body

[Peter J. Holzer]

On 2007-12-06 15:41:48 +0100, Juerd Waalboer wrote:
[...]
> So it would make sense to rewrite bodies, and since qpsmtpd is at the
> gate already, I'd like to put the solution there. Nothing fancy, but it
> would need to support simple multipart messages.
> 
> I couldn't find documentation about rewriting the body, and a quick look
> at the plugins showed no plugin that already does something like this.
> 
> Is changing the message supported at all? Has anyone actually done it
> yet?

My old qpsmtpd tutorial
(http://www.hjp.at/projekte/qpsmtpd/tutorial.rxml) contains a plugin
which appends a signature to each message. So at least appending to a
message works. I do think that you can rewrite the whole body by simply
seeking to to the start of the body before calling
$transaction->body_write. Ah yes, $transaction->body_resetpos should do
the trick. Look in Qpsmstpd::Transaction for details.

hp

-- 
   _  | Peter J. Holzer| It took a genius to create [TeX],
|_|_) | Sysadmin WSR   | and it takes a genius to maintain it.
| |   | [EMAIL PROTECTED] | That's not engineering, that's art.
__/   | http://www.hjp.at/ |-- David Kastrup in comp.text.tex


signature.asc
Description: Digital signature

Rewriting the body

[Juerd Waalboer]

Hi,

A user ran into a problem where koi8-r encoded messages get garbled in
their user agent (Tobit Infocenter), but Windows-1251 and UTF-8 work
well. They can't easily switch to another user agent, because it's a
complete groupware solution.

So it would make sense to rewrite bodies, and since qpsmtpd is at the
gate already, I'd like to put the solution there. Nothing fancy, but it
would need to support simple multipart messages.

I couldn't find documentation about rewriting the body, and a quick look
at the plugins showed no plugin that already does something like this.

Is changing the message supported at all? Has anyone actually done it
yet?
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

Re: IDN support in SMTP?!

[Peter J. Holzer]

On 2007-12-05 12:43:50 -0500, Guy Hulbert wrote:
> On Wed, 2007-12-05 at 17:46 +0100, Peter J. Holzer wrote:
> > If somebody comes up with a good proposal I'm all for it.
> 
> Don't do it.
> 
> I spent 40 minutes trying to find out about IDN yesterday before I made
> this suggestion then.  So, here is a proposal.
> 
>  proposal
> 
> 1. Don't do anything until there is an SMTP RFC which covers IDN.

You misunderstood what I wanted a proposal for. I did not want a
proposal for IDN. I wanted one for a generalization of the parser so
that plugins can be used to change the acceptable syntax.

There are two reasons why that would be a good thing:

1) The syntax is baroque. Moving the parser from the core to a plugin
   would make the core cleaner.

2) The syntax doesn't fit everybody's needs: 
   a) Few people want to allow control characters in e-mail addresses. 
  Yet the parser must allow it because RFC 2821 says that control
  characters in E-Mail addresses are legal. Of course you can write
  a plugin which checks for "strange addresses" in the mail and rcpt
  hook, but just using a different plugin than the default would be
  cleaner.
   b) Some people want to use qpsmtpd as a test platform for new SMTP
  extensions. Of course those are the people which propably aren't
  afraid of messing with the core, but again, just being able to
  swap one plugin for another is cleaner.

hp


-- 
   _  | Peter J. Holzer| It took a genius to create [TeX],
|_|_) | Sysadmin WSR   | and it takes a genius to maintain it.
| |   | [EMAIL PROTECTED] | That's not engineering, that's art.
__/   | http://www.hjp.at/ |-- David Kastrup in comp.text.tex


signature.asc
Description: Digital signature