Glen Barber | 12 Oct 2010 02:34
Picon

Confusion about allowing missing MAIL FROM

Hello list,

I saw something in my qpsmtpd.log this evening which struck me as
unusual.  In one particular incoming message, the MAIL FROM was not
there.  A quick telnet session reproducing it follows, followed by the
list of active plugins.

I'm not aware of there being a good reason for allowing this behavior,
but I'd be happy to be told otherwise.

Also, for what it's worth, I've tried this with and without
'dont_require_anglebrackets' enabled, both resulting in the same
behavior.  Ultimately, I'm curious if this is expected, or if I've found
a bug.

Best regards, and thank you for the great program.

-- log output --
220 myhostname ESMTP qpsmtpd 0.84 ready; send us your mail, but not your
spam.
helo myhostname
250 myhostname Hi myotherhostname [myip]; I am so happy to meet you.
mail from:
250 <>, sender OK - how exciting to get mail from you!
rcpt to:me <at> myhostname
250 <me <at> myhostname>, recipient ok
data
354 go ahead
quit
221 myhostname closing connection. Have a wonderful day.
(Continue reading)

Glen Barber | 12 Oct 2010 15:47
Picon

Re: Confusion about allowing missing MAIL FROM

On 10/11/10 8:34 PM, Glen Barber wrote:
> Hello list,
> 
> I saw something in my qpsmtpd.log this evening which struck me as
> unusual.  In one particular incoming message, the MAIL FROM was not
> there.  A quick telnet session reproducing it follows, followed by the
> list of active plugins.
> 
> I'm not aware of there being a good reason for allowing this behavior,
> but I'd be happy to be told otherwise.
> 

Meh.. I just realized double-bounces don't set MAIL FROM.  Sorry for the
noise...

--

-- 
Glen Barber

Peter J. Holzer | 13 Oct 2010 23:54
Picon
Favicon

Re: Confusion about allowing missing MAIL FROM

On 2010-10-11 20:34:10 -0400, Glen Barber wrote:
> I saw something in my qpsmtpd.log this evening which struck me as
> unusual.  In one particular incoming message, the MAIL FROM was not
> there.  A quick telnet session reproducing it follows, followed by the
> list of active plugins.
> 
> I'm not aware of there being a good reason for allowing this behavior,
> but I'd be happy to be told otherwise.
> 
> Also, for what it's worth, I've tried this with and without
> 'dont_require_anglebrackets' enabled, both resulting in the same
> behavior.  Ultimately, I'm curious if this is expected, or if I've found
> a bug.
> 
> Best regards, and thank you for the great program.
> 
> -- log output --
> mail from:
> 250 <>, sender OK - how exciting to get mail from you!

IMO this is a bug. A completely missing reverse path (instead of the
usual empty path <> for bounces) isn't allowed by RFC 5321 and I see no
reason to be lenient in this case (at least unless
dont_require_anglebrackets is enabled.

	hp

--

-- 
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
(Continue reading)

Glen Barber | 13 Oct 2010 23:59
Picon

Re: Confusion about allowing missing MAIL FROM

On 10/13/10 5:54 PM, Peter J. Holzer wrote:
> On 2010-10-11 20:34:10 -0400, Glen Barber wrote:
>> I saw something in my qpsmtpd.log this evening which struck me as
>> unusual.  In one particular incoming message, the MAIL FROM was not
>> there.  A quick telnet session reproducing it follows, followed by the
>> list of active plugins.
>>
>> I'm not aware of there being a good reason for allowing this behavior,
>> but I'd be happy to be told otherwise.
>>
>> Also, for what it's worth, I've tried this with and without
>> 'dont_require_anglebrackets' enabled, both resulting in the same
>> behavior.  Ultimately, I'm curious if this is expected, or if I've found
>> a bug.
>>
>> Best regards, and thank you for the great program.
>>
>> -- log output --
>> mail from:
>> 250 <>, sender OK - how exciting to get mail from you!
> 
> IMO this is a bug. A completely missing reverse path (instead of the
> usual empty path <> for bounces) isn't allowed by RFC 5321 and I see no
> reason to be lenient in this case (at least unless
> dont_require_anglebrackets is enabled.
> 

dont_require_anglebrackets is enabled, but I've reproduced it with it
disabled as well.

(Continue reading)

David Favor | 15 Oct 2010 20:31
Favicon
Gravatar

qpsmtpd-v0.84 seems to ignore size_threshold

Using qpsmtpd latest:

    root <at> hive1:# git-describe
    v0.84-36-g0b0e4e9

In lib/Qpsmtpd/Transaction.pm I see...

     $self->body_spool if ( $self->{_body_size} >= $self->size_threshold() );

I have config/size_threshold set to 10000.

Starting qpsmtpd, the log shows:

    14886 in config(size_threshold)
    14886 config(size_threshold): hook returned (0, )
    14886 trying to get config for size_threshold
    14886 setting _config_cache for size_threshold to [10000] from get_qmail_config and returning it
    14886 size_threshold set to 10000

Dumping the transaction hash for a small message I see...

    "_body_array" => undef,
    "_body_current_pos" => 9,
    "_body_file" => bless( \*Symbol::GEN6, 'IO::File' ),
    "_body_size" => 213,
    "_body_start" => 188,
    "_filename" => "/root/tmp/1287166697:13580:0",

_body_size is 213 which is smaller than 10000.

(Continue reading)

David Favor | 22 Oct 2010 21:30
Favicon
Gravatar

Transaction.pm body_fh() badly broken [was: qpsmtpd-v0.84 seems to ignore size_threshold]

Since no one responded to my previous email I've
combed through the code and found the problem.

root <at> hive1:# git-describe
v0.84-36-g0b0e4e9

perldoc lib/Qpsmtpd/Transaction.pm says...

    body_fh( )
        Returns the file handle to the temporary file
        of the email. This will return undef if the file
        is not opened (yet). In hook_data( ) or later you can
        force spooling to disk by calling $transaction->body_filename.

This use to be true and at some point the body_fh() code changed to:

    sub body_fh {
        my ($self) =  <at> _;
        # Spool to disk if we weren't already doing so
        $self->body_spool() unless $self->{_filename};
        return $self->{_body_file};
    }

Per the documentation this subroutine should be a single line:

        return $self->{_body_fh};

Lord knows when this code changed or what other code written
depends on this change.

(Continue reading)

qpsmtpdfrose.20.ftumsh | 28 Oct 2010 15:20
Favicon

How to drop an email and have global history

Lo,

Here's the problem: I have a few third party servers (openas2) that can 
generate an absolute blizzard of error emails.
These errors tend to be repeats. eg can't connect to another server 
would generate the same error each time a connection attempt was made.
I want to write a plugin takes these emails and only forwards a 
percentage of them.

Up to now I have a plugin that parses the emails and works out what sort 
of error it is.

What I am unsure how to do is...

1) Have some sort of data structure accessible to all qpsmtpd children 
that remembers if a particular error has already been received in the 
past N minutes.
I'm guessing memcached would be useful here or a sqlite db?

2) How to quietly drop an email. ie just forget I received it. I don't 
want to send an error back to the originator, nor do I wish to deliver 
it to the intended recipient.

Warmly

John

Matt Sergeant | 28 Oct 2010 16:26
Favicon

Re: How to drop an email and have global history

On Thu, 28 Oct 2010, qpsmtpdfrose.20.ftumsh <at> spamgourmet.com wrote:

> 1) Have some sort of data structure accessible to all qpsmtpd children that 
> remembers if a particular error has already been received in the past N 
> minutes.
> I'm guessing memcached would be useful here or a sqlite db?

Yes or some sort of db file like BDB, though lots of people seem to have 
reliability problems with those (myself included).

Any chance the Message-Id is the same for all these emails?

> 2) How to quietly drop an email. ie just forget I received it. I don't want 
> to send an error back to the originator, nor do I wish to deliver it to the 
> intended recipient.

You need a queue plugin (or hook) which pretends to deliver and returns 
OK, but basically does nothing.

Matt.

qpsmtpdfrose.20.ftumsh | 28 Oct 2010 17:20
Favicon

Re: How to drop an email and have global history

Matt Sergeant - matt <at> sergeant.org wrote:
> On Thu, 28 Oct 2010, qpsmtpdfrose.20.ftumsh <at> spamgourmet.com wrote:
>
>> 1) Have some sort of data structure accessible to all qpsmtpd 
>> children that remembers if a particular error has already been 
>> received in the past N minutes.
>> I'm guessing memcached would be useful here or a sqlite db?
>
> Yes or some sort of db file like BDB, though lots of people seem to 
> have reliability problems with those (myself included).
>
Ah ok.

> Any chance the Message-Id is the same for all these emails?
>
No, they're all different.
>> 2) How to quietly drop an email. ie just forget I received it. I 
>> don't want to send an error back to the originator, nor do I wish to 
>> deliver it to the intended recipient.
>
> You need a queue plugin (or hook) which pretends to deliver and 
> returns OK, but basically does nothing.
>
I currently have a plugin that has a hook_data_post. I presume I can put 
a hook_queue in the same plugin. Is there some sort of notes mechanism 
for communicating between hooks, like AxKit2?

John

(Continue reading)

Chris Lewis | 28 Oct 2010 20:22
Favicon

Re: How to drop an email and have global history

On 10/28/2010 11:20 AM, qpsmtpdfrose.20.ftumsh <at> spamgourmet.com wrote:
> Matt Sergeant - matt <at> sergeant.org wrote:

>> You need a queue plugin (or hook) which pretends to deliver and
>> returns OK, but basically does nothing.
>>
> I currently have a plugin that has a hook_data_post. I presume I can put
> a hook_queue in the same plugin.

Of course.

> Is there some sort of notes mechanism
> for communicating between hooks, like AxKit2?

The notes mechanism works across plugins and hooks. It doesn't work 
across individual email transactions.  IOW: you get a new one when the 
MAIL FROM happens.  For example, I generate a sessionid at MAIL FROM in 
a note(), and can refer to it at every subsequent plugin/hook for the 
rest of the lifetime of the email transaction.  It's part of the log 
record I produce in a postqueue hook in a different plugin.

If you're trying to get around a downstream mail server temporarily 
down/slow, you probably do NOT want to silently discard.  The sender 
thinks it's sent and dequeues it, and you lose legit email that way.

Better to have the queue plugin return a temporary failure and the 
sender will retry.  Since bots don't retry, even if your filters missed 
it, the bot won't bother.

My smtpforward plugin knows how to failover between multiple outbound 
(Continue reading)


Gmane