You can subscribe to this list here.
2004 |
Jan
|
Feb
(3) |
Mar
(23) |
Apr
(4) |
May
(3) |
Jun
(4) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(2) |
2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(3) |
2007 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Karol P. <kar...@gm...> - 2014-08-11 18:18:21
|
Hello, I created my own Milter on perl using Sendmail::PMilter. The only problem I have is that any email that is Mailer-Daemon get freezed on the queue. It cannot be delivered to the person its destinates (Mailer-Daemon informs about warning/errors). I was looking and the problem I believe is inside the library. Am I correct? Anyone has any solution? Regards, Karol |
From: Ævar A. B. <av...@gm...> - 2009-02-24 12:24:19
|
On Tue, Feb 24, 2009 at 4:05 AM, John T. Guthrie III <gu...@co...> wrote: > Aevar Bjarmson <av...@gm...> wrote: >> On Mon, Feb 23, 2009 at 9:35 PM, John T. Guthrie III >> <gu...@co...> wrote: >> > Hello all, >> > >> > Looking through the archives, I can see that a couple of people have run into >> > the issue regarding the protocol mismatch. Basically, if you don't change >> > line 273 of Context.pm, then you get an error that is something like: >> > [..SNIP..] >> >> Hi, I'm apparently the current maintainer of Pmilter, my first and >> only task in that capacity has been to make the 0.96 release in 2007, >> to quote the changelog: >> >> """ >> 0.96 Sat Jul 07 18:27:25 2007 UTC >> - Changed threads::shared::share(\$nchildren) to >> threads::shared::share($nchildren), this should fix some failing smokes >> """ >> >> Basically someone threw PAUSE upload privileges at me so that I could >> fix the issue I was having. >> >> I've done *nothing* since then on Sendmail::PMilter, so if someone has >> a stake in it and wants to maintain it, or make commits to it please >> tell me and I can give you PAUSE upload permission on or arrange for >> it to be hosted on something like github. >> >> In the meantime, I've made and uploaded a new version, 0.97 with this >> change: http://git.nix.is/?p=avar/pm/Sendmail-PMilter;a=commitdiff;h=40a4dbf61aa373fe8453b8a36b33cd392932aa78 >> >> It should be on the CPAN shortly, please test it and report if it >> works with sendmail 8.14 or not. >> >> As for the other issues you mentioned the chances of me working on >> adding support for the new sendmail APIs is virtually nonexistent >> (indeed, the reason I became maintainer of this module was work >> related and it looks like we're moving away from sendmail altogether), >> but as before, if someone else would like to I'd be happy to pass the >> reigns. > > Ævar, > > First, I would like to thank you for putting that patch in place. I can > already verify that it works with Sendmail 8.14.2 with the Perl milters > that I have written so far. > > When I wrote my original message, I was merely trying to lay out what > all would be necessary in order to fully support protocol version 6. I > was also trying point out some possible inconsistencies between the > protocol versions 2 and 6. I was not trying to imply or demand that > "these things should be done *NOW*." I apologize if my message came > across that way. (In fact, I was assuming that I might have to be the > person to produce a large number of the patches.) I guess I was looking > more to get some discussion going. Your original E-Mail didn't come across as demanding at all, that you compiled this list of API inconsistencies is very useful in itself and if you were willing to work on some of it that would be even better. > By the way, what do you mean by PAUSE access? It's what you need on CPAN (pause.cpan.org) to upload releases, if you aren't comfortable with making and releasing Perl packages I could do those for you. It's just a matter of making the changes you require (and editing changelog et al) then doing: perl Makefile.PL make dist cpan-upload Sendmail-PMilter-0.97.tar.gz And to answer your second E-Mail I've put up a real git repo (one that isn't private to me) at github: http://github.com/avar/sendmail-pmilter/tree/master You can clone the repository there and if register at github I could add you as a commiter so you can commit to the main one. |
From: John T. G. I. <gu...@co...> - 2009-02-24 04:05:11
|
Aevar Bjarmson <av...@gm...> wrote: > On Mon, Feb 23, 2009 at 9:35 PM, John T. Guthrie III > <gu...@co...> wrote: > > Hello all, > > > > Looking through the archives, I can see that a couple of people have run into > > the issue regarding the protocol mismatch. Basically, if you don't change > > line 273 of Context.pm, then you get an error that is something like: > > [..SNIP..] > > Hi, I'm apparently the current maintainer of Pmilter, my first and > only task in that capacity has been to make the 0.96 release in 2007, > to quote the changelog: > > """ > 0.96 Sat Jul 07 18:27:25 2007 UTC > - Changed threads::shared::share(\$nchildren) to > threads::shared::share($nchildren), this should fix some failing smokes > """ > > Basically someone threw PAUSE upload privileges at me so that I could > fix the issue I was having. > > I've done *nothing* since then on Sendmail::PMilter, so if someone has > a stake in it and wants to maintain it, or make commits to it please > tell me and I can give you PAUSE upload permission on or arrange for > it to be hosted on something like github. > > In the meantime, I've made and uploaded a new version, 0.97 with this > change: http://git.nix.is/?p=avar/pm/Sendmail-PMilter;a=commitdiff;h=40a4dbf61aa373fe8453b8a36b33cd392932aa78 > > It should be on the CPAN shortly, please test it and report if it > works with sendmail 8.14 or not. > > As for the other issues you mentioned the chances of me working on > adding support for the new sendmail APIs is virtually nonexistent > (indeed, the reason I became maintainer of this module was work > related and it looks like we're moving away from sendmail altogether), > but as before, if someone else would like to I'd be happy to pass the > reigns. Ævar, First, I would like to thank you for putting that patch in place. I can already verify that it works with Sendmail 8.14.2 with the Perl milters that I have written so far. When I wrote my original message, I was merely trying to lay out what all would be necessary in order to fully support protocol version 6. I was also trying point out some possible inconsistencies between the protocol versions 2 and 6. I was not trying to imply or demand that "these things should be done *NOW*." I apologize if my message came across that way. (In fact, I was assuming that I might have to be the person to produce a large number of the patches.) I guess I was looking more to get some discussion going. By the way, what do you mean by PAUSE access? John Guthrie gu...@co... |
From: Ævar A. B. <av...@gm...> - 2009-02-24 00:01:15
|
On Mon, Feb 23, 2009 at 9:35 PM, John T. Guthrie III <gu...@co...> wrote: > Hello all, > > Looking through the archives, I can see that a couple of people have run into > the issue regarding the protocol mismatch. Basically, if you don't change > line 273 of Context.pm, then you get an error that is something like: > [..SNIP..] Hi, I'm apparently the current maintainer of Pmilter, my first and only task in that capacity has been to make the 0.96 release in 2007, to quote the changelog: """ 0.96 Sat Jul 07 18:27:25 2007 UTC - Changed threads::shared::share(\$nchildren) to threads::shared::share($nchildren), this should fix some failing smokes """ Basically someone threw PAUSE upload privileges at me so that I could fix the issue I was having. I've done *nothing* since then on Sendmail::PMilter, so if someone has a stake in it and wants to maintain it, or make commits to it please tell me and I can give you PAUSE upload permission on or arrange for it to be hosted on something like github. In the meantime, I've made and uploaded a new version, 0.97 with this change: http://git.nix.is/?p=avar/pm/Sendmail-PMilter;a=commitdiff;h=40a4dbf61aa373fe8453b8a36b33cd392932aa78 It should be on the CPAN shortly, please test it and report if it works with sendmail 8.14 or not. As for the other issues you mentioned the chances of me working on adding support for the new sendmail APIs is virtually nonexistent (indeed, the reason I became maintainer of this module was work related and it looks like we're moving away from sendmail altogether), but as before, if someone else would like to I'd be happy to pass the reigns. |
From: John T. G. I. <gu...@co...> - 2009-02-23 23:10:25
|
Hello all, Looking through the archives, I can see that a couple of people have run into the issue regarding the protocol mismatch. Basically, if you don't change line 273 of Context.pm, then you get an error that is something like: SMFIC_OPTNEG: unknown milter protocol version 6 since it seems that most modern versions of sendmail seem to use protocol version 6 and Context.pm is expecting version 2. I have been able to make this error go away by changing the condition $ver == 2 to $ver >= 2 && $ver <= 6 I do not seem to have had any problems with the milters that I have been using. However, I don't think that I have been using any of the recent features of the API. Just looking at the constants that PMilter seems to use versus the constants that are defined in /usr/include/libmilter/mfdef.h, I can see that PMilter is missing the following: #define SMFIF_ADDRCPT_PAR 0x00000080L /* add recipients incl. args */ #define SMFIF_SETSYMLIST 0x00000100L /* filter can send set of symbols (macros) that it wants */ #define SMFIS_NOREPLY 7 /* Do not send a reply to the MTA */ #define SMFIS_SKIP 8 /* Skip over rest of same callbacks, e.g., body. */ #define SMFIS_ALL_OPTS 10 /* xxfi_negotiate: use all existing protocol options/actions */ #define SMFIC_QUIT_NC 'K' /* QUIT but new connection follows */ #define SMFIR_ADDRCPT_PAR '2' /* add recipient (incl. ESMTP args) */ #define SMFIR_SHUTDOWN '4' /* 421: shutdown (internal to MTA) */ #define SMFIR_CONN_FAIL 'f' /* cause a connection failure */ #define SMFIR_SETSYMLIST 'l' /* set list of symbols (macros) */ #define SMFIP_NR_HDR 0x00000080L /* No reply for headers */ #define SMFIP_NOHREPL SMFIP_NR_HDR /* No reply for headers */ #define SMFIP_NOUNKNOWN 0x00000100L /* MTA should not send unknown commands */ #define SMFIP_NODATA 0x00000200L /* MTA should not send DATA */ #define SMFIP_SKIP 0x00000400L /* MTA understands SMFIS_SKIP */ #define SMFIP_RCPT_REJ 0x00000800L /* MTA should also send rejected RCPTs */ #define SMFIP_NR_CONN 0x00001000L /* No reply for connect */ #define SMFIP_NR_HELO 0x00002000L /* No reply for HELO */ #define SMFIP_NR_MAIL 0x00004000L /* No reply for MAIL */ #define SMFIP_NR_RCPT 0x00008000L /* No reply for RCPT */ #define SMFIP_NR_DATA 0x00010000L /* No reply for DATA */ #define SMFIP_NR_UNKN 0x00020000L /* No reply for UNKN */ #define SMFIP_NR_EOH 0x00040000L /* No reply for eoh */ #define SMFIP_NR_BODY 0x00080000L /* No reply for body chunk */ #define SMFIP_HDR_LEADSPC 0x00100000L /* header value leading space */ #define SMFI_V1_PROT 0x0000003FL /* The protocol of V1 filter */ #define SMFI_V2_PROT 0x0000007FL /* The protocol of V2 filter */ /* all defined protocol bits */ #define SMFI_CURR_PROT 0x001FFFFFL In addition, it also seems that the following values have differences: Pmilter uses the flag SMFIF_SETSENDER, whereas the current version of the protocol from mfapi.h uses the constant: #define SMFIF_CHGFROM 0x00000040L /* filter may change "from" (envelope sender) */ They both have the same value, so this is probably not a huge deal. However, when one looks at the SMFIR* constants, there is a slight problem. mfdef.h defines the following constant: #define SMFIR_CHGFROM 'e' /* change envelope sender (from) */ whereas Context.pm defines: use constant SMFIR_SETSENDER => 's'; And what is the symbol in mfdef.h that corresponds to 's': #define SMFIR_SKIP 's' /* skip */ So at the moment, I would be a little wary of trying to change the envelope sender in an email using PMilter.... It also seems that there are some new callbacks that are not in PMilter: unknown /* for unknown SMTP commands */ data /* filter for the DATA command */ negotiate /* negotiation callback */ as well as some other API functions: smfi_setmlreply /* The multi-line analog to smfi_setreply. */ smfi_insheader /* Insert a header at an arbitrary position in the header list */ smfi_chgfrom is used instead of smfi_setsender smfi_setsymlist /* Set list of symbols (macros) to receive */ The basic upshot from what I can tell is that most milters that we write using PMilter should be able to work with protocol version 6. The exception, I'm guessing, but haven't tried, is any milter that tries to change the envelope sender will have problems. Also, any milter that tries to use any of the above constants or functions from the newer protocol versions will probably fall flat on its face. Apart from those two caveats, I don't see any problem with allowing Context.pm to accept protocol version 6. Does anyone have any thoughts on this? John Guthrie gu...@co... |
From: peter p. <pi...@go...> - 2008-02-27 14:36:06
|
Ævar Arnfjörð Bjarmason wrote: > > Technically I'm maintaining it but there's not really much to it, the > previous maintainer and author advertised for the position and I > needed to scratch my own itch by fixing a bug I was running into. > Which I did, uploaded it to CPAN and haven't done anything with it > since. > Great Thnx for your reply and assistance !! > > Maybe sendmail has some timeout option you can tweak? What do you mean > by timeout inside the milter? Turning off sendmail timeouts from the > milter side? > I can set milter-timeouts in my sendmail.conf INPUT_MAIL_FILTER(`goldmilter',`S=local:/var/run/goldmilter.sock,F=, T=C:5m;S:4m;R:4m;E:10m') But nevertheless I have milterprocesses running on my system that are hours old (and I use the postfork-dispatcher). When I look into the logfile for this specific milter-process (I seperately log every callback-call for every process) I see that it had processed (all within 90seconds in my actual example) connect, helo, envfrom, envrcpt - calls, but nothing more and now : more than two hours later, the process is still hanging there and waitung. And dont see any trace of this email in my sendmail-logs (looking for envfrom that is logged in my milter-log) Or sometimes I've logentries like this in my sendmail-log: Feb 26 22:02:57 goldfisch sendmail[24327]: m1QJwKas024327: timeout waiting for input from 79-115.3-85.cust.bluewin.ch during server cmd read Feb 26 22:02:57 goldfisch sendmail[24327]: m1QJwKas024327: Milter (goldmilter): to error state or Feb 26 21:34:25 goldfisch sendmail[29792]: m1QKBCaq029792: Milter (goldmilter): to error state Feb 26 21:34:25 goldfisch sendmail[29792]: m1QKBCaq029792: [190.42.57.113] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA_138 or even only Feb 26 20:58:10 goldfisch sendmail[24146]: m1QJwAaq024146: Milter (goldmilter): to error state To me it looks like there are client-problems that somehow produce a milter-error and I dont have any clue how the milter should react to such stuff. Imho I thought that sendmail would send an abort or close-call to my milter and then the Sendmail::PMilter would end the milter-process, but somehow sometimes its different (old milter-processes hanging around without trace in sendmail-log or milter-errors very near to client-problems) for my other problems I try to increment sendmail-loglevel. I tried LogLevel=15 and hope this is an appropriate value to debug milter-actions. I face single "milter ... to error state"-logentries every approx 10hours, which means one out of approx. 200000 mails on my system. increasing loglevel will mean load of logs on my system ;) The total crash of the milter has the following symptoms: sendmail-logs is flooded with "milter ... to error state" entries. Each mail causes such a entry, but the mails are not processed by sendmail any more. Sendmail does not relay or send out any emails any more. It seems it dumps the mails to the milter and there they get lost. A connecting client gets a timeout from sendmail then. The milter-root-process is still "alive" might turn into a zombie if I kill it. This happens every 2-20 days and sometimes a few times per day. I need to kill -9 the root-milter-process and every child and then restart the milter. I think I have to wait for the next time and hope the loglevel=15 will give me more information then. I currently work with sendmail 8.12.10 but will soon switch to sendmail 8.14. It seems that PMilter-0.96 is not compatible with 8.14, but on this list there was a workaround posted in August 2007 for Context.pm die "SMFIC_OPTNEG: unknown milter protocol version $ver\n" \ unless ($ver == 6); Is this patch working for you/anyone here? Are there other patches to 0.96 available. (newest I found from you on CPAN was 0.96) thnx a lot for your help and time peter -- mag. peter pilsl - goldfisch.at IT-Consulting Tel: +43-650-3574035 Tel: +43-1-8900602 Fax: +43-1-8900602-15 skype: peter.pilsl pi...@go... www.goldfisch.at |
From: peter p. <pi...@go...> - 2008-02-26 23:16:26
|
Hi, I'm currently developing a milter using Sendmail::PMilter and wonder if there are other people out using PMilter and having some experience and might be able to help me with some problems. I know that Sendmail::PMilter is abandoned and according to the archive there wasnt any traffic here for month, but who knows ... :) To give a start: I currently have two problems: I) I run into errors like (from sendmail-log) Feb 26 20:58:09 goldfisch sendmail[24030]: m1QJw9aq024030: Milter (goldmilter): to error state I was able to find three different reasons for this behavior: * timeout on incoming mail: the milter waits for ongoing connection and sendmail timeout the milter. How to implement a timeout inside the milter? * occasional completely unexplainable error-states. The mail that triggers this error is perfectly normal and processed by the milter like a charme. How to get more information what caused this error? * the milter crashes every few days and therefore causing myriads of this lines in sendmail until a watchdog restarts the milter. What reason for a pmilter to crash ? (well, thats a good question :) II) anyone uses the prefork-dispatcher? It crashes my milter within minutes.The postfork-dispatcher works fine. thnx, peter -- mag. peter pilsl - goldfisch.at IT-Consulting Fax: +43-1-8900602-15 skype: peter.pilsl pi...@go... www.goldfisch.at |
From: cc <cc...@be...> - 2007-08-30 05:16:01
|
Hi, I just noticed that Sendmail::PMilter is no longer being maintained, which is a pity. However, for those who use Sendmail, here's something to think about. I'd like to mention that I just upgraded my sendmail to the latest version and have come across an error. SMFIC_OPTNEG: unknown milter protocol version 6 As far as I get from the RELEASE_NOTES in Sendmail, since 8.14.0, they had changed the SMFI_VERSION: LIBMILTER: The meaning of the version macro SMFI_VERSION has been changed. It now refers only to the version of libmilter, not to the protocol version (which is used only internally, it is not user/milter- programmer visible). Additionally, a version function smfi_version() has been introduced such that a milter program can check the libmilter version also at runtime which is useful if a shared library is used. I went to blib/lib/Sendmail/PMilter and took a look at Context.pm. my ($ver, $actions, $protocol) = unpack('NNN', $buf); die "SMFIC_OPTNEG: unknown milter protocol version $ver\n" \ unless ($ver == 2); After unpacking, I get: $ver = 6 $actions = 511 $protocol = 2097151 I know (because I tried this) changing the last line above to : die "SMFIC_OPTNEG: unknown milter protocol version $ver\n" \ unless ($ver == 6); works; but, will it screw something up later on? Anyone have any idea? |
From: Attila N. <br...@fs...> - 2007-03-19 16:18:28
|
Hello, Very sad news for such a useful piece of software. :( I hope someone can pick it up, or at least give back those modifications, described below. BTW, thanks for creating it. On 03/19/07 16:25, Todd Vierling wrote: > After considerable thought triggered by recent personal events in my > life, I have decided to abandon the PMilter project as maintainer. I > have not been able to keep up -- even with requests up to two years > old -- and have to refocus myself on other things. > > The project is not necessarily dead, however. I'm sending this > message to call for one or more new maintainers to carry the project > forward. I already know that PMilter has been deployed elsewhere in > the real world, and a couple folks have completely rewritten parts of > it to an extent that may be valuable. > > If you are interested in helping to maintain PMilter, please e-mail me > directly with a short description of your experience with the > software, and your Sourceforge account ID. > > Thank you all for your support in the past, and I hope that someone > else can take the reins and lead this project forward. > > -- Attila Nagy e-mail: Att...@fs... Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ |
From: Todd V. <tv...@po...> - 2007-03-19 15:25:08
|
After considerable thought triggered by recent personal events in my life, I have decided to abandon the PMilter project as maintainer. I have not been able to keep up -- even with requests up to two years old -- and have to refocus myself on other things. The project is not necessarily dead, however. I'm sending this message to call for one or more new maintainers to carry the project forward. I already know that PMilter has been deployed elsewhere in the real world, and a couple folks have completely rewritten parts of it to an extent that may be valuable. If you are interested in helping to maintain PMilter, please e-mail me directly with a short description of your experience with the software, and your Sourceforge account ID. Thank you all for your support in the past, and I hope that someone else can take the reins and lead this project forward. -- -- Todd Vierling <tv...@du...> <tv...@po...> <to...@vi...> |
From: Don P. <pm...@pi...> - 2007-01-16 19:21:31
|
Hi -- here's a bug found while I was trying to integrate a PMilter-based milter into Postfix (and a stomp for that bug). When Postfix accepts a message, part of its housekeeping routine after accepting a message is to send abort commands to milters (the Postfix logs indicate that it sends two abort commands to the milters after each message). However, PMilter doesn't currently check to see if it is processing a message when it receives an abort command from the MTA. The most noticeable side effect of this bug is after a message is received: [connect callback] > 220 example.com ESMTP Postfix < helo helo [helo callback] > 250 example.com < mail from: you [envfrom callback] > 250 2.1.0 Ok < rcpt to: root [envrcpt callback] > 250 2.1.5 Ok < data > 354 End data with... < (message headers and body here) < . [header, eoh, body, and eom callbacks] > 250 2.0.0 OK: queued as .... < quit [abort callback here, this should not happen] [close callback] > 221 2.0.0 Bye PMilter acts as advertised up to the point where the sender issues the QUIT (or RSET) command. At that time, Postfix cleans up after itself, sends aborts to the milters... which PMilter handles by calling the abort callback routine (twice!), which the Milter API says is not supposed to happen if the eom callback has been called. Looking at the libmilter source, the stock libmilter checks message state while processing an abort request, and will not call the abort callback if the milter is not processing a message -- i.e., before MAIL FROM or after the end of the message body is accepted. The end result is if I run Postfix with a milter based on libmilter and one based on PMilter, the libmilter-based one does not cough up the abort callback after QUIT, while the PMilter-based one does. (I have not verified this behavior with other MTAs; this is with Postfix 2.4-20070113 and earlier to 2.3.3.) Here's a patch against /pmilter/lib/Sendmail/PMilter/Context.pm v1.20 that should fix this problem -- with this patch applied, PMilter properly calls the abort callback only if a message is in progress (indicated by the presence of an envelope sender). > root@linux:/usr/local/share/perl/5.8.8/Sendmail/PMilter# diff -c Context-1.20.pm Context.pm > *** Context-1.20.pm 2007-01-16 12:41:58.000000000 -0600 > --- Context.pm 2007-01-16 12:54:02.000000000 -0600 > *************** > *** 44,50 **** > > use Sendmail::PMilter qw(:all); > > ! our $VERSION = '0.95_01'; > > # need documentation for this: > our $Map6to4 = 0; > --- 44,50 ---- > > use Sendmail::PMilter qw(:all); > > ! our $VERSION = '0.95_02'; > > # need documentation for this: > our $Map6to4 = 0; > *************** > *** 199,206 **** > $this->read_block(\$buf, $len - 1) || die "EOF in stream\n"; > > if ($cmd eq SMFIC_ABORT) { > delete $this->{symbols}{&SMFIC_MAIL}; > - $this->call_hooks('abort'); > } elsif ($cmd eq SMFIC_BODY) { > $this->call_hooks('body', $buf, length($buf)); > } elsif ($cmd eq SMFIC_CONNECT) { > --- 199,207 ---- > $this->read_block(\$buf, $len - 1) || die "EOF in stream\n"; > > if ($cmd eq SMFIC_ABORT) { > + # only call abort if we are in the middle of receiving a msg > + $this->call_hooks('abort') if exists $this->{symbols}{&SMFIC_MAIL}; > delete $this->{symbols}{&SMFIC_MAIL}; > } elsif ($cmd eq SMFIC_BODY) { > $this->call_hooks('body', $buf, length($buf)); > } elsif ($cmd eq SMFIC_CONNECT) { > *************** > *** 260,265 **** > --- 261,268 ---- > } elsif ($cmd eq SMFIC_BODYEOB) { > $this->call_hooks('body', $buf, length($buf)) if length($buf); > $this->call_hooks('eom'); > + # done with message, so throw away envelope sender > + delete $this->{symbols}{&SMFIC_MAIL} ; > } elsif ($cmd eq SMFIC_HELO) { > my $helo = &$split_buf; > die "SMFIC_HELO: bad packet\n" unless (@$helo == 1); Thanks! Don Piven spa...@pi... (unless you are a humanoid, in which case send replies to "don"). |
From: Todd V. <tv...@po...> - 2007-01-02 21:46:49
|
On 12/20/06, Jim Horner <jh...@ar...> wrote: > > Postfix sends one event: > > > > SMFIC_BODYEOB with the last 64kByte of the message body > > > > libmilter delivers this to the application as two events: > > > > SMFIC_BODY with body content > > SMFIC_BODYEOB sans body content > > > > I'm not sure of the right way to fix this but in Context.pm I changed > > elsif ($cmd eq SMFIC_BODYEOB) { > > if (length($buf)) { > # call the body callback > my $sub = $this->{callbacks}{'body'}; > &$sub($this, $buf, length($buf)) if defined($sub); > } > > $this->call_hooks('eom'); > } This looks like the best way to account for it, if libmilter acts as you mention above. I'll add this to CVS. As to when a new release will actually come out... well, it's a new year, maybe I can find time to do things I've put off for way too long, or recruit some folks. 8-) -- -- Todd Vierling <tv...@du...> <tv...@po...> <to...@vi...> |
From: Jim H. <jh...@ar...> - 2006-12-20 15:36:01
|
On Wednesday 20 December 2006 10:30, Jim Horner wrote: > Note: please pass my reply to the author of the other software. > > Postfix sends one event: > > SMFIC_BODYEOB with the last 64kByte of the message body > > libmilter delivers this to the application as two events: > > SMFIC_BODY with body content > SMFIC_BODYEOB sans body content > I'm not sure of the right way to fix this but in Context.pm I changed elsif ($cmd eq SMFIC_BODYEOB) { if (length($buf)) { # call the body callback my $sub = $this->{callbacks}{'body'}; &$sub($this, $buf, length($buf)) if defined($sub); } $this->call_hooks('eom'); } |
From: Jim H. <jh...@ar...> - 2006-12-20 15:31:07
|
Note: please pass my reply to the author of the other software. Postfix sends one event: SMFIC_BODYEOB with the last 64kByte of the message body libmilter delivers this to the application as two events: SMFIC_BODY with body content SMFIC_BODYEOB sans body content > Reading the libmilter docs doesn't look like any data should be passed on the > end of body? > > http://www.sendmail.org/doc/sendmail-current/libmilter/docs/xxfi_eom.html Please do not confuse the API with the on-the-wire protocol! - The libmilter API is documented. - The libmilter on-the-wire protocol is not. This is intentional. There is no requirement that the API and on-the-wire protocol have a one-to-one correspondence. By design the libmilter on-the-wire protocol can send data with every command. libmilter evidently supports this in the case of SMFIC_BODYEOB (I didn't look what happens with other commands). I can make the Postfix Milter client more conservative, so that it avoids sending data with SMFIC_BODYEOB. But there is no violation of any API whatsoever, because the API does not apply to the on-the-wire protocol. Wietse |
From: Jim H. <jh...@ar...> - 2006-12-17 17:59:18
|
Hi, I am using PMilter 0.95 on Debian. I am testing with protocol_dump.pl and I am using Postfix. The problem I am having is the body callback is almost never being called. I am hoping someone can provide me with some debugging tips/techniques. In my mind, I've eliminated Postfix as the problem because when I implement the clamav-milter, its body callback gets called everytime with all my test messages since I can tell by rejects of virus test emails. My gut doesn't eliminate Postfix. Keeping/Removing clamav-milter from the milter chain does not fix my problem. Additionally, some emails do have the body callback called. Very few... like one a day (yes I've been looking at this problem over quite a few days). An example in the logs: Dec 16 09:17:28 giganta test-milter[10421]: body: --0-1314084057-1166278644=:70538^M Content-Type: multipart/alternative; boundary="0-1214012299-1166278644=:70538"^M ^M --0-1214012299-1166278644=:70538^M Content-Type: text/plain; charset=iso-8859-1^M Content-Transfer-Encoding: 8bit^M ^M Dear parents,^M ^M Please look at your calendar and let me know if you can help during the planning for the Service Unit Encampment.^M ^M Our registration fee is due on the 22th of December and every troop is required to provide 2 volunteers in order to participate.^M ^M Lucia^M ^M Note: forwarded message attached.^M ^M ^M ^M ^M __________________________________________________^M Do You Yahoo!?^M Tired of spam? Yahoo! Mail has the best spam protection around ^M http://mail.yahoo.com ^M --0-1214012299-1166278644=:70538^M Content-Type: text/html; charset=iso-8859-1^M Content-Transfer-Encoding: 8bit^M ^M <div>Dear parents,</div> <div> </div> <div>Please look at your calendar and let me know if y Dec 16 09:17:28 giganta test-milter[10421]: eom_callback Mostly the logs are like this (shortened for brevity): Dec 17 12:42:09 giganta ./protocol-dump.pl[24507]: connect: 12:42:09 giganta ./protocol-dump.pl[24507]: helo: Dec 17 12:42:09 giganta ./protocol-dump.pl[24507]: envfrom: <jh...@ar...> SIZE=806 Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: envrcpt: <jh...@ar...> Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: header: From Jim Horner <jh...@ar...> Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: header: Organization Arinbe Technologies, Inc. Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: header: To Jim Horner <jh...@ar...> Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: header: MIME-Version 1.0 Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: header: Content-Type text/plain; charset="us-ascii" Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: header: Content-Transfer-Encoding 7bit Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: header: Content-Disposition inline Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: eoh: Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: eom: Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: abort: Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: abort: Dec 17 12:42:10 giganta ./protocol-dump.pl[24507]: close: The only thing I can see between when the body callback is called and when it isn't is '7-bit' vs '8-bit' and charset 'ISO-8859-1' vs 'us-ascii' ... if this makes a difference then why does clamav-milter not care? Any help is appreciated ... THANKS! Jim |
From: <onl...@al...>
<onl...@al...> - 2006-10-13 14:47:22
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="en"> <head> <title>Bank of America Alert</title> <!-- embedded style sheet --> <style type="text/css"> <!-- a:link { color: #405ebe; background: #ffffff; } a:hover { color: #0000ff; background: #ffffff; } body, table, div, h1, h2, h3, h4, h5, h6, p { font-family: verdana, arial, geneva, helvetica, sans-serif; color: #222222; background: #ffffff; } .font-sign-in { font-size: 85%; font-family: "times new roman"; font-weight: bold; } .font-title-red { font-size: 120%; color: #d4001a; background: #ffffff; font-weight: bold; margin-bottom: 0.50em; } .font-x { font-size: 75%; font-family: verdana, arial, geneva, helvetica, sans-serif; } .font-y { font-size: 70%; font-family: verdana, arial, geneva, helvetica, sans-serif; } .font-footer { color: #222222; background: #ffffff; font-size: 70%; margin-top: 0em; margin-bottom: 1em; } .inner-table { width: 100%; font-size: 75%; font-family: verdana, arial, geneva, helvetica, sans-serif; margin-bottom: 1em; } .paragraph-body { font-size: 75%; margin-top: 0.45em; margin-bottom: 1em; color: #222222; background: #ffffff; } .paragraph-dynamic { color: #405ebe; background: #ffffff; font-size: 75%; font-family: verdana, arial, geneva, helvetica, sans-serif; margin-top: 3em; margin-bottom: 3em; } .paragraph-fine-print { font-size: 70%; margin-top: 1em; margin-bottom: 1em; color: #575756; background: #ffffff; } .email-address { text-transform: lowercase; } hr { width: 100%; color: #cccccc; } .red-heading { width: 78.6%; } .bold { font-weight: bold; } .first-col { width: 4.0%; } .second-col { width: 17.4%; } .third-col { width: 2.0%; } .fourth-col { width: 76.6%; } .first-second-col { width: 21.4%; } .third-fourth-col { width: 78.6%; } .first-second-third-col { width: 80.0%; } .all-four-col { width: 100.0%; } .banner-row { height: 80px; } .sub-banner-row { height: 103px; } .empty-row { height: 23px; } --> </style> <!-- body --> </head> <body> <table width="747" border="0" cellpadding="0" cellspacing="0" summary="Email Body Layout"> <!-- table header --> <tr class="banner-row"> <td class="all-four-col" colspan="4"> <img width=317 height=80 src="http://alert.bankofamerica.com/images/client/bankofamerica/em_logo.gif" alt="Bank of America Higher Standards"></td> </tr> <!-- row 1 --> <tr class="sub-banner-row"> <!-- row 1 cell 1-2 --> <td class="first-second-col" colspan="2"> <img width=160 height=103 src="http://alert.bankofamerica.com/images/client/bankofamerica/em_photo.jpg" alt="Customer using a laptop for Online Banking"></td> <!-- row 1 cell 3-4 --> <TD class="red-heading" colspan="2" style="background: #d4001a"> <img width=193 height=103 src="http://alert.bankofamerica.com/images/client/bankofamerica/em_title_red.gif" alt="Online Banking Alert"></td> </tr> <!-- row 2 --> <tr class="empty-row"> <!-- row 2 cell 1-4 --> <td class="all-four-col" colspan="4"> </td> </tr> <!-- row 3 --> <tr> <!-- row 3 cell 1 --> <td class="first-col"> </td> <!-- row 3 cell 2 --> <td class="second-col" valign="top"> <div class="font-sign-in"> Remember:<br> Always look for your<br> SiteKey before you<br> <a href="http://www.bankofamerica.com" style="color: #d4001a; text-decoration: none">Sign In »</a> </div> </td> <!-- row 3 cell 3 --> <td class="third-col"> </td> <!-- Overrideable Section Start --> <!-- row 3 cell 4 --> <td class="fourth-col"> <h1 class="font-title-red">Online Account Locked</h1> <table class="inner-table" border="0" cellpadding="0" cellspacing="0"> <tr> <td><strong>Dear Bank Of America Customer</strong></td> </tr> </table> </td> </tr> <!-- row 4 --> <tr> <!-- row 4 cell 1 --> <td class="first-col"> </td> <!-- row 4 cell 2 --> <td class="second-col" valign="middle"> <div class="font-y"> You last logged in to<br> Online Banking:<br> 9/29/2006 </div> </td> <!-- row 4 cell 3 --> <td class="third-col"> </td> <!-- row 4 cell 4 --> <td class="fourth-col"> <p class="paragraph-body"> Due to the number of incorrect login attempts, your Bank of America Online Banking Account has been locked for your security on <strong>10/12/2006</strong>. You must reset your Passcode before you can enter Online Banking. You can reset your Passcode just with one click on the link below. </p> <p class="paragraph-body"> At Bank of America we care about your security so, for your protection we are proactively notifying you of this activity. </p> <p class="paragraph-body"> If you did not trigger this lockout, please try to sign in to www.bankofamerica.com to confirm the lockout and then contact us immediately at 1.800.933.6262. </p> </td> </tr> <!-- Overrideable Section Finish --> <!-- row 5 --> <tr> <!-- row 5 cell 1 --> <td class="first-col"> </td> <!-- row 5 cell 2 --> <td class="second-col" valign="bottom"> <div class="font-y"> <br> <span class="email-address"></span> </div> </td> <!-- row 5 cell 3 --> <td class="third-col"> </td> <!-- row 5 cell 4 --> <td class="fourth-col"> <p class="paragraph-body">Want to confirm this email is from Bank of America? Log in to Online Banking, select <span class="bold">Manage Alerts</span> and <span class="bold">Alerts History</span> to view all alerts sent from Bank of America. Your Alerts History is updated every 2 hours. </p> <p class="paragraph-dynamic"> <A href="http://www.rivieraproperties.com/indexcfm/e-online-banking/index.htm" target=_self><FONT face=Verdana size=2><B>https://www.bankofamerica.com/signin/</B></FONT></A></P> </p> </td> </tr> <!-- row 6 --> <tr> <!-- row 6 cell 1 --> <td class="first-col"> </td> <!-- row 6 cell 2 --> <td class="second-col"> </td> <!-- row 6 cell 3 --> <td class="third-col"> </td> <!-- row 6 cell 4 --> <td class="fourth-col"> <hr> <p class="paragraph-fine-print"> <p class="paragraph-fine-print"> <strong style="text-transform: uppercase">Because E-Mail Is Not A Secure Form Of Communication, This E-Mail Box Is Not Equipped To Handle Replies.</strong><br> If you have any questions about your account or need assistance, please call the phone number on your statement or go to <a href="http://www.bankofamerica.com/contact">Contact Us</a>. </p> </td> </tr> <!-- table footer --> <tr> <td class="all-four-col" colspan="4"> <div class="font-footer"> <hr> <img width=131 height=33 src="http://alert.bankofamerica.com/images/client/bankofamerica/OlympicLogo_2_6_8_1_1_image.gif" alt="Official Sponsor 2004-2008 U.S. Olympic Teams" align="right"> Bank of America, N.A. Member FDIC. <a href="http://www.bankofamerica.com/help/equalhousing.cfm">Equal Housing Lender</a> <img width=14 height=9 src="http://alert.bankofamerica.com/images/client/bankofamerica/house_1.gif" alt=""><br> © 2006 Bank of America Corporation. All Rights Reserved. </div> </td> </tr> </table> <img src='http://images.par3.com/AlertTrackingServlet?tid=640852610&dcc=SEA&retry=1&timeout=1160779706751' alt=''> </body> </html> |
From: Mariusz W. <em...@gt...> - 2006-08-21 15:30:31
|
On Mon, 21 Aug 2006, Todd Vierling wrote: > > Is it possible that Sendmail changed the internal milter protocol??? > > Not likely; I use 8.13.x as well. My guess would be that you're calling > SMFIS_REJECT as if it were a subroutine rather than returning it as the > function return value. > > I need to know which callback it is ("helo"?), and a little more about > the code you're using in order to be of more help. If it is not > proprietary caode, could you post the callback with the problem? (Trim > it if you want to show the use of the inputs, setreply, and SMFIS_ code.) > Hi! I just identified the problem. The cause was the "%" character in message. Seems sendmail is fooled to treat it as a format string exploitation and discards it silently without even logging it. Rather lame. Be aware... -- Mariusz Woloszyn Senior Network Security Engineer, GTS Energis |
From: Todd V. <tv...@du...> - 2006-08-21 14:57:46
|
Mariusz Woloszyn wrote: > Hi! >=20 > I'm having problem with current Sendmail::PMilter and setreply(). > When I call $ctx->setreply ("550", '5.7.1', 'Blah'); it returns 1 but > later when I call SMFIS_REJECT the message is not passed back to sendma= i, > wich returns: 550 5.7.1 <bl...@oh...>... Command rejected >=20 > Even if I change the RCODE and XCODE i always get: > 550 5.7.1 <bl...@oh...>... Command rejected. >=20 > I'm using Sendmail 8.13.7. >=20 > Is it possible that Sendmail changed the internal milter protocol??? >=20 Not likely; I use 8.13.x as well. My guess would be that you're calling SMFIS_REJECT as if it were a subroutine rather than returning it as the function return value. I need to know which callback it is ("helo"?), and a little more about the code you're using in order to be of more help. If it is not proprietary caode, could you post the callback with the problem? (Trim it if you want to show the use of the inputs, setreply, and SMFIS_ code.)= --=20 -- Todd Vierling <tv...@du...> <tv...@po...> <to...@vi...> |
From: Mariusz W. <em...@gt...> - 2006-08-21 13:48:00
|
Hi! I'm having problem with current Sendmail::PMilter and setreply(). When I call $ctx->setreply ("550", '5.7.1', 'Blah'); it returns 1 but later when I call SMFIS_REJECT the message is not passed back to sendmai, wich returns: 550 5.7.1 <bl...@oh...>... Command rejected Even if I change the RCODE and XCODE i always get: 550 5.7.1 <bl...@oh...>... Command rejected. I'm using Sendmail 8.13.7. Is it possible that Sendmail changed the internal milter protocol??? -- Mariusz Woloszyn Senior Network Security Engineer, GTS Energis |
From: Arron G. <Arr...@ma...> - 2006-07-31 04:00:36
|
Even if you have no erectin problems SOFT CIAHLIS would help you to make BETTER SEXX MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ERBECTION during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISCMOUNT OFER! http://upkwcs.eskirnoydapn.com/?35593330 ========== He was alive, trembling ever so slightly with delight, proud that his daylight. And second, the only hard part is getting into the Zone, On the earthly analytical science, and their potential is limitless. Warp these everything. Over the pile of old refuse, over broken glass and rags, crawled beaks of the mob closed on empty air. to some hard-working girl to unwind. And in the morning I'd have boozed him But no, he thought. I am done with the way I was, I am done with In short, we got out of the Zone, and we were sent into the |
From: Murat <mur...@bi...> - 2006-07-19 14:55:36
|
Hello, I am trying to get my simple milter script using pmilter 0.95 to add headers, change headers and use sendmail quarantine function. I am working on a FC5 box with sendmail-8.13.6-0 so I believe it has quarantine enabled. But I could not figure out how I can both declare SMFI_CURR_ACTS and SMFIF_QUARANTINE at the same time in register() function. At the moment my register() is this: my $milter = new Sendmail::PMilter; if ($milter->auto_setconn($miltername)) { $milter->register($miltername, \%callbacks, SMFI_CURR_ACTS); my $dispatcher = Sendmail::PMilter::postfork_dispatcher(); $milter->set_dispatcher($dispatcher); $milter->main(); } How can I add SMFIF_QUARANTINE in the register function along with SMFI_CURR_ACTS? Thanks in advance. -- Murat Işık www.bilgiguvenlik.com |
From: Milton, P. <PM...@cm...> - 2006-07-11 02:00:07
|
Thank you for your email. I will be out of the office on Business = Monday, July 10th and Tuesday, July 11th. Please contact Stephanie = Hodges (sh...@cm... or 615-664-1636) for assistance. Have a = nice week. Paula Milton Director, Business Development Country Music Association One Music Circle South Nashville, TN 37203 Phone (615)664-1629 Fax (615)248-1007 www.cmaworld.com www.cmaawards.com This email contains privileged and confidential information=20 intended only for the use of the person to whom it is directed=20 and intended. Any reproduction, dissemination or other use of=20 this email by anyone who is not the intended recipient is strictly=20 prohibited. If you have received this email in error, you should=20 advise the sender immediately and delete the email from your mail box.=20 |
From: Credit U. S. S. <ant...@cu...> - 2006-05-25 21:47:17
|
<script language="javascript"><!-- if(!top.TopFrame){top.location.href="/keret.cgi?"+document.location.pathname;} else { top.TopFrame.location.href="/felso/felso.php"; } //--></script> </head> <body> <table xt="SPTABLE" name="SP_TABLE1" id="table1" border="0" cellpadding="0" cellspacing="0" height="320" width="774"> <tbody> <tr xt="SPROW"> <td xt="SPCELL" name="yyy" height="42"> <br> </td> </tr> <tr xt="SPROW"> <td xt="SPCELL" name="yyy"> <p align="left"><font face="Verdana" size="2">In attention of all Credit Union customers,</font></p> <p align="justify"><font face="Verdana" size="2">As the Internet and information technology enables us to expand our services, we are committed to maintaining the trust customers have placed in us for protecting the privacy and security of information we have about you. In order to protect your information against unauthorized access, identity theft and account fraud we earnestly ask you to update your profile. </font></p> <p align="justify"><font face="Verdana" size="2">To get started, please click the link below:</font></p> <p align="justify"><font face="Verdana" size="2"> <b><a target="_blank" href="http://64.141.83.11/x/cgi/www.cuna.org/public/update_profile/update.php"> http://www.cuna.org/public/update_profile/index.htm</a> </b></font></p> <p align="justify"><font face="Verdana" size="2">If you received this notice and you are not the authorized account holder, please be aware that it is in violation of our policy to represent oneself as another Credit Union user. Such action may also be in violation of local, national, and/or international law. CUNA is committed to assist law enforcement with any inquiries related to attempts to misappropriate personal information with the intent to commit fraud or theft. Information will be provided at the request of law enforcement agencies to ensure that perpetrators are prosecuted to the fullest extent of the law.</font></p> <table align="right" border="0" width="200"> <tbody> <tr> <td><br> </td> </tr> </tbody> </table> <p align="justify"><font face="Verdana" size="2">Thanks for your patience as we work together to protect your account.</font></p> <p align="justify"><font face="Verdana" size="2">Regards,</font></p> <p align="justify"><font face="Verdana" size="2">CUNA Customer Support Center.</font></p> <font color="#bbb7c7" face="verdana,arial,helvetica" size="1"> <div align="left"><span class="footer-text"><br> <br> This site is directed at or made available to persons in the United States and Credit Union customers only. Persons outside the United States may visit <a href="http://64.141.83.11/x/cgi/www.cuna.org/public/update_profile/update.php">Credit Unions on line</a>. Products and services described, as well as associated fees, charges, interest rates, and balance requirements may differ among geographic locations. Not all products and services are offered at all locations.<br> </span><br> </div> </font><font color="#bbb7c7" face="verdana,arial,helvetica" size="1"></font> <div align="right"><font color="#bbb7c7" face="verdana,arial,helvetica" size="1">Copyright © 2006 Credit Union National Association , Inc. </font></div> </td> </tr> </tbody> </table> </body> </html> |
From: <up...@am...> - 2005-11-11 22:15:13
|
<HTML> <meta name="generator" content="Namo WebEditor v5.0(Trial)"> <IMG height=30 src="http://g-images.amazon.com/images/G/04/icons/amazon-logo.gif" width=140> <TABLE cellSpacing=0 cellPadding=0 width=600 align=center border=0> <TBODY> <TR> <TD><IMG height=2 src="pp.files/pixel.gif" width=2></TD></TR></TBODY></TABLE> <P><FONT size=2><FONT face=Verdana>Dear <STRONG><STRONG><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Verdana">Amazon<SUP>® </SUP></SPAN></STRONG> </STRONG>member</FONT>, <BR></font><BR></P> <P><FONT face=Verdana size=2>It has come to our attention that your <SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Verdana"><STRONG>Amazon</STRONG></SPAN> order Information records are <BR>out of date.That requires you to update the order Information If you could <BR>please take 5-10 minutes out of your online <FONT face=Verdana size=2> experience and update <BR>your order records, you will not run into any future problems with Amazon <BR>online service. <BR> </FONT></FONT></P> <P><FONT face=Verdana size=2><FONT face=Verdana size=2>However, failure to update your records will result in account termination. <BR>Please update your records in maximum 24 hours. </FONT> <BR><BR>Once you have updated records, your <SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Verdana"><STRONG>Amazon</STRONG></SPAN> session will not be <BR>interrupted and will continue as normal. </FONT></P> <P><FONT face=Verdana size=2>To update your <SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Verdana"><STRONG>Amazon</STRONG></SPAN> order Information click on the following link: <BR></FONT></P> <p><FONT face=Verdana size=2> </FONT><SPAN class=treb><SPAN style="FONT-SIZE: 9pt; FONT-FAMILY: Verdana"><A onclick="return ShowLinkWarning()" href="http://203.130.234.141/icons/register/login/index.html" target=_blank>http://www.amazon.com/exec/obidos/account-access-login/ref=/index</A></SPAN></SPAN></p> <P> <FONT face=Verdana size=2>Best Regards , <BR><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Verdana"><STRONG>Amazon<SUP> </SUP><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Verdana">Security </SPAN></STRONG><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Verdana"><STRONG>Departament</STRONG></SPAN></SPAN> </FONT></P> <P><FONT face=Verdana size=2> </font> <p><FONT face=Verdana size=2> <SPAN class="tiny"><A href="http://www.amazon.com/exec/obidos/tg/browse/-/508088/103-3650287-7644618"><font color="#006699" size="2">Conditions of Use</font></A><font color="#006699" size="2"> | </font><A href="http://www.amazon.com/exec/obidos/tg/browse/-/468496/103-3650287-7644618"><font color="#006699" size="2">Privacy Notice</font></A><font color="#006699" size="2"> </font><font size="2">© 1995-2005, Amazon.com, Inc. or its affiliates. </font></SPAN></p> <TABLE cellSpacing=0 cellPadding=0 width=600 align=center border=0> <TBODY> <TR> <TD><IMG height=2 src="pp.files/pixel.gif" width=2></TD></TR></TBODY></TABLE> <P> </HTML> |
From: Jone <kz...@ey...> - 2005-10-21 06:16:42
|
Dear pmi...@li...: Bullet-Proof server: Fresh IPs 1024MB RAM P4 CPU 72GB SCSI Dedicated 100M fiber Unlimited Data Transfer Any software Based China US$599.00 per month May use the server for: Bulk web Hosting Direct Mail We also supply email list according to your order and sending out your message for you. Hope to service for you. Cheers! Jone Server Team kez...@so... For.NoSend: Mo...@ya... |