$final_bad_header_destiny = D_BOUNCE and Return-Path: <>, mail gets delivered unscanned

[Hans Spaans]

Leonard den Ottolander schreef op za 13-07-2013 om 23:32 [+0200]:
> Hello Hans,
> 
> On Sat, 2013-07-13 at 18:00 +0200, Hans Spaans wrote:
> > The default is D_PASS, so did you change it or does Fedora supply amavis
> > with this setting?
> 
> This is indeed a setting as shipped by Fedora EPEL. Not sure what Fedora
> the distro does, but I'd guess they might be doing the same.

A REJECT with Sendmail milter could be understandable, but then again it
is still to strict in most case and will cause unhappy people that will
start playing with other default settings until things "work".

It need to create RHEL systems soon so maybe also a Fedora flavored one
can be added as well to check this. I'm surprised ;-)

> If this is an invalid configuration then perhaps it should not be
> possible to configure amavis this way? But if amavis *can* be configured
> this way I'd say the mail wiggling itself from the quarantine should at
> least be scanned by spamassassin.

Invalid and undesired are two different this. The behaviour is as
undesired as how Qmail and Exchange have (had) the same undesired
behaviour by accepting any e-mail and then bounce it when the user
didn't exist on the system.

Only in this case your system can't bounce it back as the return path is
already empty. Like sad it isn't invalid, but undesired and that is why
amavis has a default configuration set to or DISCARD or PASS messages.
With BOUNCE amavis will send the DSN (Delivery Status Notification) and
with REJECT the MTA will generate the DSN.

So setting it to PASS will solve you problem and let the user decide
what to do or give him advise through SpamAssassin solves close to 100%
of the use cases. Also you could turn on some checks in Postfix, see
postconf | grep ^strict_ , but those are off for the same reason.

> >  If the later is the case, then a bugreport may be
> > wise. Bouncing after an OK on the SMTP DATA phase will get you
> > blacklisted sooner or later. I prefer sooner btw ;-)
> 
> Since I originally sent this email (with a different subject) a few
> weeks ago I have altered my configuration to $final_bad_header_destiny =
> D_PASS.
> 
> > > Received: from unknown (HELO localhost)
> > >  (from at domain.ru@2.2.2.2) by 1.1.1.1 with ESMTPA;
> > 
> > Source routing, haven't seen that one for years. You're willing to
> > publish the IP?
> 
> Well, actually all the messages that managed to get through by using
> this "no return path" trick do this. Could be a dozen or more.

It isn't a trick but a special purpose address as you shouldn't block
e-mail from that address. That was also why it was/is a populair address
for Sender Address Verification.

> This particular address has a name that suggests a dynamic IP network
> under the domain vologda.ru (shpd-2-2-2-2.vologda.ru).

It appears to be gone :(

> > > The missing date header puts the mail in quarantine and the missing
> > > Return-Path breaks the bouncing so the mail gets sent without having
> > > been scanned by spamassassin:
> > 
> > Yes and no, the missing return-path is there to break the mail loop that
> > otherwise could emerge. It is a special case, you may want to read RFC
> > 2822 if I'm not mistaken.
> > 
> > > 
> > <cut>
> > > 
> > > And the mail gets delivered to my mailbox.
> > 
> > You have setup amavis to use your address as an administrator address or
> > something like it?
> 
> No that would be postmaster and there is no translation from the
> postmaster address to my email address. Only the straight forward email
> -> user translation.
> 
> Jun 14 12:51:54 host postfix/virtual[2220]: D642542:
> to=<user at domain.nl>, orig_to=<email at domain.nl>, relay=virtual,
> delay=0.11, delays=0.07/0.01/0/0.04, dsn=2.0.0, status=sent (delivered
> to maildir)
> 
> It's not like the message is being handled as a quarantine after the
> bounce has failed. Amavis hands it back to postfix which delivers it.

Rereading you logs indicated that the mail/notification is submitted to
the user on purpose. The line with FWD indicated that. I missed that
earlier, sorry.

> > > How can I assure that mail that fails to bounce at least gets scanned by
> > > spamassassin?
> > 
> > Reading your logs, your DKIM setup appears to be broken as it tries to
> > sign a non-local domain, but doesn't has the right keys luckily. You may
> > want to follow the submission port style signing if you mix a receiving
> > MTA with a sending MTA on the same box.
> 
> Last year when I was looking into DKIM I added 0.0.0.0/8 to @mynetworks
> as per the instructions at
> http://www.ijs.si/software/amavisd/amavisd-new-docs.html section "For
> the impatient - signing from scratch".
> 
> At that time I didn't give it any thought, but looking into this in
> relation to this issue the adding of this network seemed very wrong, so
> I removed that addition to @mynetworks. See also my mail from June 16th.
> 
> I didn't make the effort to add DKIM signing yet.

If memory serves me right the following config modification should be
enough to DKIM sign your e-mail for authenticated users. You should have
the right records in DNS btw and the file locations may be different.

/etc/postfix/master.cf
submission inet n       -       n       -       -       smtpd
  -o content_filter=lmtp-amavis:[127.0.0.1]:10026
  ...

/etc/amavis/conf.d/50-user
$inet_socket_port = [10024,10026];
$enable_dkim_signing = 1;
$signed_header_fields{'received'} = 0;
@dkim_signature_options_bysender_maps = (
    { '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );
$interface_policy{'10026'} = 'ORIGINATING';
$policy_bank{'ORIGINATING'} = {
  originating => 1,
  smtpd_discard_ehlo_keywords => ['8BITMIME'],
};

/etc/amavis/conf.d/60-dkim (auto generated for now)
dkim_key("example.org","submission.0","/etc/amavis/dkim/example.org-submission.0.pem");

But if you give me a copy of your config I can have a look if I see
something that could help you. You're still using version 2.8.0 right?

Regards,
Hans

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.amavis.org/pipermail/amavis-users/attachments/20130714/c10484f1/attachment.sig>