Libere su movil desde 12 euros !

[Thanos Massias]

On Fri, 3 Jun 2005 12:35:20 -0600, Charles Cazabon
<qmail@...> wrote :

> Thanos Massias <tm@...> wrote:
> >
> > Out of curiosity, what options does one have for serial deliveries of
> > e-mail besides 'serialmail'?
> >
> > Is there a way to treat messages as files, pre-compress them, transfer
> > them via some efficient file transfer protocol to another server, have
> > them decompressed on the other side and injected on qmail's queue (with
> > the original MAIL FROM & RCPT TO arguments)?
>
> What you're looking for is called "uucp".  It's a dying protocol, but there
> are still providers that do uucp.
>
> Charles

Thanks.

--
Best regards,
Thanos Massias

[Michael Martinell]

> -----Original Message-----
> From: Kelvin Williams [mailto:kelvin-ml@...]
> Sent: Friday, June 24, 2005 7:57 PM
> To: qmail@...
> Subject: Moving to Qmail
>
> Does anyone have any advice on moving to a Qmail server from an existing
> server?  In particular, the user's email on the existing server.
>
>
>
> We are planning to use Qmail for a client who is an ISP that has decided
> to bring their email operation in house (it has been outsourced).  We have
> know all of the user's email addresses, unfortunately because their
> current provider encrypts the password we don't' have those.  However, we
> are using vpopmail with the -enable-password-learning on.
>
>
>
> What I'd like to do, is make the change to the DNS server so they will
> begin hitting the new mailserver.  However, immediately upon their first
> connection I'd like to fire off a process that connects to the existing
> server, and fetches all the email that is there.  This will solve two
> problems: 1) user's will not miss any mail, and 2) will give us a 'grace
> period' for the DNS change to propogate.
>
>
>
> Is this a bad idea?  Or does anyone have any better suggestions (or
> reading material).
>
>
>
> Thanks in advance.
>
> kw

This is how we just accomplished a similar move:
1. Set up qmail server with new virtual domain
2. Set up users email account on the mail server
3. Sent out emails to users informing them of the change, when it would be
and what their new settings would be.  Also told them to make sure to do a
send/receive before they changed their settings.
4. Had ISP change the 10 level mx record to us
5. Had ISP change the 20 level mx record to them (just in case)
6. Used fetchmail to get mail to users new accounts (scripted process) After
the procedure was over in case there was any mail left at the ISP.
7. We didn't lose any mail

Hope this helps

[Thanos Massias]

On Wed, 29 Jun 2005 06:47:21 -0500, hbeaumont hbeaumont <ahlist@...>
wrote :

>
> Hi,
>
> Can anyone recommend a method to stop local users from sending mail from
> certain addresses? I want to stop exploited mailer scripts, etc. that users
> have on their websites from sending mail from addresses such as
> paypal.com<http://paypal.com>,
> ebay.com <http://ebay.com>, etc. (banning scripts that send mail is not an
> option :(
>
> I didn't know if qmail has any certain way to do this built-in. Adding these
> to badmailfrom would also deny "real" mail from those addresses coming in
> remotely. I just want to stop any local outgoing mail that has those
> addresses as the from domain.
>
> Any ideas?
>
> Would writing a custom wrapper around qmail-inject / sendmail be the best
> way?
>

I take it that you are talking about local message injections (the
'qmail-inject' part) thus an SMTP level filter is of no use to you.

A qmail-inject wrapper is possible but you should know exactly how
qmail-inject is invoked.
I believe that something like this might work for tapping qmail-inject:
--------------------------------
#!/bin/sh
valpid=$$
(
echo Arguments are: $*
echo Environment is:
env
) > /tmp/qmail-inject.pid.$valpid

exec /var/qmail/bin/qmail-inject $*
--------------------------------
Then you can see what you need to look for in your filters.

A half-baked idea that comes to mind is changing the code of the qmail-tap
patch from inter-7 in a way that if no match is found either in the senders
or in the recipients lists, then substitute the recipients list with a
recipient of your own (log them or send them to the bitbucket).
This would mean that, since this is done at qmail-queue level, all
deliveries (localy injected or remotely injected) are filtered.


If, however, I understood wrong and the messages in question are injected to
your qmail via SMTP from the webservers that create them (and they use
spoofed MAIL FROMs), then you can try the goodmailfrom patch from Dion Sasmito:

http://www.metesek.com/projects/qmail-gmfcheck/project_qmail-gmfcheck.php


--
Best regards,
Thanos Massias

[Thanos Massias]

On Wed, 29 Jun 2005 17:27:11 -0500, "Rob" <rbailleu@...> wrote :

> I am really looking foolish now.
>
> Hi,
>
> I know this is not your usual question.  But I have a customer that got the
> following bounce. And wondered if any one knows what system is creating it.
> I did not get the full headers and will have to go to the customers to do
> so.  Just thought I would ask here first.
>
> rob
>
>
> From: System Administrator

yeah, sure

> Sent: Tuesday, June 28, 2005 4:40 PM
> To: 'Marston, Rebecca J'
> Subject: Undeliverable: Amtrak B & B Guide
>
> Your message did not reach some or all of the intended recipients.
>
>       Subject: RE: Amtrak B & B Guide
>       Sent: 6/28/2005 4:40 PM
>
> The following recipient(s) could not be reached:
>
>       'Marston, Rebecca J' on 6/28/2005 4:40 PM
>             None of your e-mail accounts could send to this recipient.
>
>

Rob,

Google is your friend (and apparently M$ isn't--not this time anyway):

http://www.google.com/search?lr=&ie=UTF-8&oe=UTF-8&q=None%20of%20your%20e-mail%20accounts%20could%20send%20to%20this%20recipient

http://support.microsoft.com/?kbid=872896

Also look this:

http://swigartconsulting.blogs.com/tech_blender/2004/12/none_of_your_em.html


--
Best regards,
Thanos Massias

[Thanos Massias]

On Wed, 29 Jun 2005 15:43:27 -0400 (EDT), "David T. Ashley"
<dta@...> wrote :

>
> > I'm at the YAPC conference right now. In a five-minute talk, Meng
> > Weng Wong gave a talk about, basically, himself. In the midst of it,
> > he said (and I paraphrase) that he's in the process of reinventing
> > email on the assumption that SMTP is bass-ackwards. On the few
> > specifics he gave, he appeared to be describing IM2000. In
> > particular, he seems to have converted to the belief that content
> > should be hosted by the sender rather than the receiver, shifting the
> > costs to the spammer (and making the spammer findable, by forcing
> > them to keep a viable account as long as they want their messages to
> > live).
> >
> > In the spirit of the completely b0rken SPF and SRS, he naturally
> > believes that this can all be accomplished by leveraging RSS in some
> > way. But it's interesting that, Venema-like, he embraces DJB's ideas
> > but claims them as his own.
>
> Len,
>
> A couple of points:
>
> a)People who have exposure to the same problems often come to the same or
> similar conclusions independently (especially when it is a logical
> conclusion).  Do you have any evidence of plagiarism?  Seriously, pushing
> the burden back to the sender is a pretty immediate concept.
>
> b)Do you have any evidence that DJB originated the ideas rather than Mr.
> Wong?  It may very well be that DJB encountered Mr. Wong's ideas and
> recognized their value.  In any professional publications, DJB would
> naturally have cited Mr. Wong, but in casual conversations, it would add
> unnecessary complexity and length to do this.
>
> Do we know for sure who first conceived some of the key concepts behind
> IM2000?
>
> Best regards, Dave.
>

Actually Mr. Budney got the IM2000 right:

From: http://moongroup.com/pipermail/spf-council/2005-June/000327.html
SPF-council IRC logs for 2005-06-15
IRC nicknames:
freeside       Meng Weng Wong
---------------------------------------------------------------------
22:08   <freeside> i'll also be giving a lightning talk on RSS/Email,
                   which is an interesting take on IM2000 that Andy
                   Newton first brought to my attention.
                   http://mengwong.com/rssemail/
---------------------------------------------------------------------

However, http://mengwong.com/rssemail/rssemail-006.pdf (p.52) reads :
---------------------------------------------------------------------
RSS/Email ? v0.06
Acknowledgements
Much of this work was fleshed out during a discussion with
Andrei Freeman on 20050404.
Andy Newton first brought the idea of RSS/Email to my
attention at maawg in early 2005.
The original concept of sender-stores messaging was first
publicized by DJB as im2000. Pioneering message systems
such as Zephyr established many of these concepts.
http://ref.web.cern.ch/ref/CERN/CNL/2003/001/zephyr/
---------------------------------------------------------------------
so, Mr. Wong already gave proper credit to Mr. Bernstein and in written.


--
Best regards,
Thanos Massias
 

[Leonard Budney]

On Jun 29, 2005, at 9:04 PM, Thanos Massias wrote:
>
> so, Mr. Wong already gave proper credit to Mr. Bernstein and in  
> written.

I'm glad to see that! In the talk, which was occurring as I wrote my  
email, he gave no credit to anyone. I'm pleased that he appears to be  
giving credit in other places.

--Len.

[Thanos Massias]

On Sat, 16 Jul 2005 04:54:42 +0200, John Farson <john.farson@...> wrote :

> [...]
>
> [1] http://www.fehcom.de/qmail/smtpauth.html#PATCHES
>
> [...]
>
> Example with aol.com:
>
> I add the domain to smtproutes control file:
> aol.com:relayserver.myisp.tld

Unless I missunderstood the documentation, you don't need that but it won't
hurt either. control/authsenders will do both the the routing and the
authentication and has priority over control/smtproutes.

>
> I add the domain to authsenders control file:
> aol.com:relayserver.myisp.tld|myuser|mypass

This is correct syntax for control/authsenders. control/authsenders has the
same syntax as control/smtproutes with the addition of the "|user|password"
data.

>
> I don't know if that i want to do is possible with this patch, someone
> who uses it could guide me?
>

It should work, provided that 'relayserver.myisp.tld' supports AUTH of types
PLAIN or LOGIN (anyone will do). Test this by doing a
'telnet relayserver.myisp.tld 25'

Then this dialog should take place. You type the C: (client) statement
'EHLO client.example.com' (use your host's fully qualified domain name here)
and the MTA responds with the S: (server) lines:

S: 220 relayserver.myisp.tld ESMTP
C: EHLO client.example.com
S: 250-relayserver.myisp.tld
S: 250-PIPELINING
S: 250-8BITMIME
S: 250-SIZE 255555555
S: 250 AUTH LOGIN PLAIN CRAM-MD5

In this example we see, from the last line, that the remote server supports
AUTH of types PLAIN and LOGIN (you need at least one of those) and also
CRAM-MD5 (which the patch doesn't support for qmail-remote).

--
Best regards,
Thanos Massias

[Thanos Massias]

On Sat, 16 Jul 2005 06:11:45 -0400, "U. George" <gatgul@...> wrote :

> Is there a way to throttle these service requests?
>
> [...]
>

A guess:

rblsmtpd issues a temporary rejection code (451) but the client ignores it
(as many malware would). This typicaly happens with malware that just go
through all the message sending sequence ignoring any responce codes
(sometimes called as " presumptuous clients" because they "presume" that the
server accepts all their input). A common source is spam relayed via open
http proxies.


In you case, it goes something like this:
- client sends SMTP commands. The imporatnt part is the envelope FROM and
RCPT(s)
- rblsmtpd accepts (actually ignores) HELO, EHLO, MAIL, RSET, NOOP but
answers 451 to any other SMTP command. Thus it answers 451 to RCPT so the
client should QUIT and go away (temporarily). But...
- client ignores 451 to RCPT and proceeds to DATA as if all was well
- rblsmtpd deals with each line the client sends as if it was some SMTP
command and, as described above, issues one 451 for each line. That is why
you get all these lines in your logs.


This is normal and doesn't mean that your connections need throttling.


If however one was to deal with such cases in a more active way, an
*untested* half-baked idea that comes to mind is modifying rblsmtpd.c so
that this struct:
-----------------------
struct commands smtpcommands[] = {
  { "quit", quit, 0 }
, { "helo", accept, 0 }
, { "ehlo", accept, 0 }
, { "mail", accept, 0 }
, { "rset", accept, 0 }
, { "noop", accept, 0 }
, { 0, reject, 0 }
} ;
-----------------------
becomes:
-----------------------
struct commands smtpcommands[] = {
  { "quit", quit, 0 }
, { "helo", accept, 0 }
, { "ehlo", accept, 0 }
, { "mail", accept, 0 }
, { "rset", accept, 0 }
, { "noop", accept, 0 }
, { "data", quit, 0 }
, { "get", quit, 0 }
, { "head", quit, 0 }
, { "post", quit, 0 }
, { 0, reject, 0 }
} ;
-----------------------
This will 'alias' GET, POST & GET (http commands--common when the connection
comes from an abused open http proxy) and DATA to QUIT [-> _exit(0)].

I haven't tested but it looks it should work (but then again...)




--
Best regards,
Thanos Massias

[Richard Lyons-2]

On 16 Jul 2005, Thanos Massias wrote:

> This will 'alias' GET, POST & GET (http commands--common when the connection
> comes from an abused open http proxy) and DATA to QUIT [-> _exit(0)].
>
> I haven't tested but it looks it should work (but then again...)

We do this on some of our spam traps and have had no hits in the
last couple of months.  I speculate this is because spammers have
found that exploiting CONNECT gives better results.

Rick.

[Thanos Massias]

On Sun, 17 Jul 2005 01:15:58 +1000 (EST), Richard Lyons
<frob-qmail@...> wrote :

> On 16 Jul 2005, Thanos Massias wrote:
>
> > This will 'alias' GET, POST & GET (http commands--common when the connection
> > comes from an abused open http proxy) and DATA to QUIT [-> _exit(0)].
> >
> > I haven't tested but it looks it should work (but then again...)
>
> We do this on some of our spam traps and have had no hits in the
> last couple of months.  I speculate this is because spammers have
> found that exploiting CONNECT gives better results.
>
> Rick.

Very clever--nothing in the message reveals that it comes from an http proxy.


--
Best regards,
Thanos Massias

[noreply-70]

Some parts of this message have been removed. Learn more about Nabble's security policy.

LIBERE SU MOVIL DESDE 12 EUROS *

 

 

Se libera dentro de 24 horas **

Podemos liberar cualquier móvil, de todas las marcas,  de todas las operadoras españolas y algunas extranjeras.  También liberamos consolas PsP, Ps2, Ds Nintendo y Wii para que puedas usar cualquier operadora en tu móvil, cargar juegos adquiridos en otros países o hacer copias de seguridad de los tuyos. No dejes tu móvil o consola en manos de cualquiera, confía sólo en los profesionales. somos liberadores oficiales de simyo el operador de telefonía libre

Para mas informacion llama tel. 971.575.110

Copyright © 2009 publicidadxemail

** Depende de marca y modelo, puede tardar hasta 48 horas
* Precio envio no incluido