Re: OT SMTP forwards broken by SPF WAS blocking smtp connections based on age of domain?

[Les Mikesell]

Juerd Waalboer wrote:

Peter J. Holzer skribis 2007-06-08 10:46 (+0200):

It occurs to me that we might not mean the same thing when we talk about
the envelope. With envelope I mean the SMTP envelope as defined in
section 2.3.1 of RFC 2821, i.e. the MAIL FROM and RCPT TO commands.
(This is also the definition used in draft-crocker-email-arch-08)


Me too, but I thought you implied wrapping everything by attaching an
rfc2822 file to a new message. Apparently you have other ways of
wrapping envelopes.


Where would you like bounces and failure delivery notices for this 
wrapped message to go?  SRS defines a kludge to make things work, but it 
has to run at the forwarding site which has no requirement to do so.  If 
 you create a new message with the old as an attachment, you'd have to 
supply new non-envelope headers as well.  Who is the From: for this new 
message?


--
  Les Mikesell
   [EMAIL PROTECTED]

Re: OT SMTP forwards broken by SPF WAS blocking smtp connections based on age of domain?

[Juerd Waalboer]

Peter J. Holzer skribis 2007-06-08 10:46 (+0200):
> It occurs to me that we might not mean the same thing when we talk about
> the envelope. With envelope I mean the SMTP envelope as defined in
> section 2.3.1 of RFC 2821, i.e. the MAIL FROM and RCPT TO commands.
> (This is also the definition used in draft-crocker-email-arch-08)

Me too, but I thought you implied wrapping everything by attaching an
rfc2822 file to a new message. Apparently you have other ways of
wrapping envelopes.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: Is qpsmtpd threadsafe? Evidence to the contrary

[Matt Sergeant]

Darren Griffith wrote:

In the following logs, we have:

 (1) our customer: tbmailer.triobet.com [83.218.12.49] on thread 16846
 (2) a spammer: OL12-45.fibertel.com.ar [24.232.45.12] on thread 16845

The spammer's server triggers the check_earlytalker plugin. Then it 
triggers

the dnsbl plugin according to a spamhaus lookup. Our customer's server is
considered white by the greylisting plugin.

The error message is this one:

box[16846]: 550 http://www.spamhaus.org/query/bl?ip=24.232.45.12

(note the wrong PID). A copy of our customer's bounce message confirms
that they received this 550 error message verbatim.

Does anyone know why this would have happened? Is qpsmtpd not 
threadsafe?


This can be caused by the dnsbl plugin if the seed for DNS has not been 
initialised randomly enough and if you don't check response ID's against 
the originating query (I can't recall if we do that or not). Which 
backend are you using? forkserver?


Matt.

Is qpsmtpd threadsafe? Evidence to the contrary

[Darren Griffith]

Hello:

We recently tracked down an instance where our qpsmtpd server rejected a
legitimate email from one of our customers, where the 550 error message from
a simultaneous thread was accidentally sent to our customer's thread. Very
strange.

In the following logs, we have:

 (1) our customer: tbmailer.triobet.com [83.218.12.49] on thread 16846
 (2) a spammer: OL12-45.fibertel.com.ar [24.232.45.12] on thread 16845

The spammer's server triggers the check_earlytalker plugin. Then it triggers
the dnsbl plugin according to a spamhaus lookup. Our customer's server is
considered white by the greylisting plugin.

The error message is this one:

box[16846]: 550 http://www.spamhaus.org/query/bl?ip=24.232.45.12

(note the wrong PID). A copy of our customer's bounce message confirms
that they received this 550 error message verbatim.

Does anyone know why this would have happened? Is qpsmtpd not threadsafe? Or
is one of the plugins (check_earlytalker, dnsbl, greylisting) not
threadsafe? The "dispatching RSET" may also be a cause---because our mail
server is within P.R. China, both sides of our SMTP connections often 
experience RSET
packets caused by the Great Firewall.

Here's a portion of the logs:

Sat May 26 15:09:34 2007 box[16846]: Accepted connection 7/40 from 83.218.12.49 
/ tbmailer.triobet.com
Sat May 26 15:09:34 2007 box[16846]: Connection from tbmailer.triobet.com 
[83.218.12.49]
Sat May 26 15:09:34 2007 box[16846]: logging::file
Sat May 26 15:09:34 2007 box[16846]: check_earlytalker
Sat May 26 15:09:35 2007 box[16845]: Accepted connection 6/40 from 24.232.45.12 / 
OL12-45.fibertel.com.ar

Sat May 26 15:09:35 2007 box[16845]: Connection from OL12-45.fibertel.com.ar 
[24.232.45.12]
Sat May 26 15:09:35 2007 box[16845]: logging::file
Sat May 26 15:09:35 2007 box[16845]: check_earlytalker
Sat May 26 15:09:35 2007 box[16845]: remote host started talking before we said 
hello [24.232.45.12]
Sat May 26 15:09:35 2007 box[16845]: check_relay
Sat May 26 15:09:35 2007 box[16845]: whitelist
Sat May 26 15:09:35 2007 box[16845]: dnsbl
Sat May 26 15:09:35 2007 box[16845]: 220 fw.exoweb.net ESMTP qpsmtpd 0.32 ready; send us your mail, 
but not your spam.

Sat May 26 15:09:35 2007 box[1495]: cleaning up after 16845
Sat May 26 15:09:35 2007 box[16846]: remote host said nothing spontaneous, 
proceeding
Sat May 26 15:09:35 2007 box[16846]: check_relay
Sat May 26 15:09:35 2007 box[16846]: whitelist
Sat May 26 15:09:35 2007 box[16846]: dnsbl
Sat May 26 15:09:35 2007 box[16846]: 220 fw.exoweb.net ESMTP qpsmtpd 0.32 ready; send us your mail, 
but not your spam.

Sat May 26 15:09:36 2007 box[16846]: dispatching HELO tbmailer.triobet.com
Sat May 26 15:09:36 2007 box[16846]: whitelist
Sat May 26 15:09:36 2007 box[16846]: check_spamhelo
Sat May 26 15:09:36 2007 box[16846]: 250 fw.exoweb.net Hi tbmailer.triobet.com [83.218.12.49]; I am 
so happy to meet you.

Sat May 26 15:09:36 2007 box[16846]: dispatching MAIL FROM:<[EMAIL PROTECTED]>
Sat May 26 15:09:36 2007 box[16846]: full from_parameter: FROM:<[EMAIL 
PROTECTED]>
Sat May 26 15:09:36 2007 box[16846]: from email address : [<[EMAIL PROTECTED]>]
Sat May 26 15:09:36 2007 box[16846]: whitelist
Sat May 26 15:09:36 2007 box[16846]: rhsbl
Sat May 26 15:09:36 2007 box[16846]: check_badmailfrom
Sat May 26 15:09:36 2007 box[16846]: greylisting
Sat May 26 15:09:36 2007 box[16846]: using /var/lib/qpsmtpd/greylisting/denysoft_greylist.dbm as 
greylisting database

Sat May 26 15:09:36 2007 box[16846]: ts: Sat May 26 15:09:30 2007, now: Sat May 
26 15:09:36 2007
Sat May 26 15:09:36 2007 box[16846]: key 83.218.12.49 is white, 21714 deliveries
Sat May 26 15:09:36 2007 box[16846]: getting mail from <[EMAIL PROTECTED]>
Sat May 26 15:09:36 2007 box[16846]: 250 <[EMAIL PROTECTED]>, sender OK - how exciting to get mail 
from you!

Sat May 26 15:09:37 2007 box[16846]: dispatching RCPT TO:<[EMAIL PROTECTED]>
Sat May 26 15:09:37 2007 box[16846]: to email address : [<[EMAIL PROTECTED]>]
Sat May 26 15:09:37 2007 box[16846]: whitelist
Sat May 26 15:09:37 2007 box[16846]: rhsbl
Sat May 26 15:09:37 2007 box[16846]: dnsbl
Sat May 26 15:09:37 2007 box[16846]: 550 
http://www.spamhaus.org/query/bl?ip=24.232.45.12
Sat May 26 15:09:37 2007 box[16846]: dispatching RSET
Sat May 26 15:09:37 2007 box[16846]: 250 OK
Sat May 26 15:09:38 2007 box[16846]: dispatching QUIT
Sat May 26 15:09:38 2007 box[16846]: 221 fw.exoweb.net closing connection. Have 
a wonderful day.
Sat May 26 15:09:38 2007 box[16846]: logging::file
Sat May 26 15:09:38 2007 box[16846]: rhsbl
Sat May 26 15:09:38 2007 box[16846]: dnsbl
Sat May 26 15:09:39 2007 box[1495]: cleaning up after 16846

Thank you.

--
Darren Paul Griffith, IT Systems Administrator
www.exoweb.net, +86 135 2262 5129

Re: OT SMTP forwards broken by SPF WAS blocking smtp connections based on age of domain?

[Peter J. Holzer]

On 2007-06-08 09:05:22 +0200, Juerd Waalboer wrote:
> Peter J. Holzer skribis 2007-06-07 21:51 (+0200):
> > > > Instead there is a break in the old transaction and a new transaction is
> > > > started.  Just like with real mail.
> > > I've often forwarded "real mail" without changing anything to the
> > > envelope, and without wrapping a new envelope around it.
> > Then how did the postman know about the address you wanted the mail to
> > be forwarded to? (Delivering yourself doesn't count: In that case you
> > are wrapping a "mental envelope" around it).
> 
> Although I was not the postman, it has been my task for a long time to
> do the internal delivery. I've never noticed any mental envelopes.

By "mental envelope" I meant that the information where the letter
really should be delivered is in your head instead of on the paper
envelope. If you get a letter addressed to Bob and you see that it is
from Foo Inc. and you know that Alice normally deals with Foo Inc. and
you conclude that the letter really should be delivered to Alice, you
are mentally constructing an outer envelope with "To: Alice" written on
it. While delivering the letter you use only this mental envelope and
ignore the "To: Bob" on the paper envelope. 

If the person deciding that the letter must be forwarded to Alice and
person who does the actual delivery are not the same, then this
information must be made explicit: For example by really putting the
letter into a new envelope with "To: Alice" on it, or by striking out
"To: Bob" on the envelope and scribbling "To: Alice" beneath it, or by
just telling the delivery guy or whatever.


> > > > That might be annoying to those who want the MUA to pretend that the
> > > > mail came directly to them but is it more annoying than having to deal
> > > > with the side effects of SPAM?
> > > To me, yes, absolutely. Spam is incredibly annoying, but rewritten
> > > envelopes interrupt my workflow more.
> > You can't avoid rewritten envelopes if you forward mail. How do you even
> > notice them? Reading the Return-Path and Received headers?
> 
> Is noticing that they were forwarded necessary for the end user, if
> forwarding is part of an intended automated process?

No. And the user does normally NOT notice it. That's why I asked how
something which you don't even notice can interrupt your workflow.

It occurs to me that we might not mean the same thing when we talk about
the envelope. With envelope I mean the SMTP envelope as defined in
section 2.3.1 of RFC 2821, i.e. the MAIL FROM and RCPT TO commands.
(This is also the definition used in draft-crocker-email-arch-08)

hp

-- 
   _  | Peter J. Holzer| I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR   | with an emu on his shoulder.
| |   | [EMAIL PROTECTED] |
__/   | http://www.hjp.at/ |-- Sam in "Freefall"


signature.asc
Description: Digital signature

Re: small problem regarding the File::DirCompare - Perl module

[James Turnbull]

bhan wrote:

Hi ,
  My requirement is  to compare two given
directories.Inorder to achieve this i have 
used File::DirCompare perl module.And i have written

the below program to get the output.
  

Try [EMAIL PROTECTED]

Regards

James Turnbull

--
James Turnbull <[EMAIL PROTECTED]>
---
Author of Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)

Hardening Linux
(http://www.amazon.com/gp/product/159059/)
---
PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)

Re: OT SMTP forwards broken by SPF WAS blocking smtp connections based on age of domain?

[Juerd Waalboer]

Peter J. Holzer skribis 2007-06-07 21:51 (+0200):
> > > Instead there is a break in the old transaction and a new transaction is
> > > started.  Just like with real mail.
> > I've often forwarded "real mail" without changing anything to the
> > envelope, and without wrapping a new envelope around it.
> Then how did the postman know about the address you wanted the mail to
> be forwarded to? (Delivering yourself doesn't count: In that case you
> are wrapping a "mental envelope" around it).

Although I was not the postman, it has been my task for a long time to
do the internal delivery. I've never noticed any mental envelopes.

> > > That might be annoying to those who want the MUA to pretend that the
> > > mail came directly to them but is it more annoying than having to deal
> > > with the side effects of SPAM?
> > To me, yes, absolutely. Spam is incredibly annoying, but rewritten
> > envelopes interrupt my workflow more.
> You can't avoid rewritten envelopes if you forward mail. How do you even
> notice them? Reading the Return-Path and Received headers?

Is noticing that they were forwarded necessary for the end user, if
forwarding is part of an intended automated process?
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>