Recent changes to feature-requests

disable/enable version functionality

Noel — Mon, 06 Oct 2008 20:34:04 -0000

I am requesting there be included an option to disable senderID, or if you like to enable only SPF (v1)

The main reason for using SPF is to reject forgers, and SenderID protocol is incredibly broken when it comes to dealing with mailing lists, SPF v1 handles these fine, this would allow those of us wanting to do what SPF is intended to do, IOW, use r2 option etc to outright block, can do so without losing legitimate mail, after much google research, senderID recommends violating smtp RFCs to overcome this, this is very wrong, so a simple option allowing us control would be better, perhaps, for example it can do by default as it does now, unless we give a -1 indicating only do SPFv1, and -2 for only do SenderID.

EG- would overcome this :
This is the Postfix program at host outgoing3.securityfocus.com.I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.For further assistance, please send mail to <postmaster>If you do so, please include this problem report. You can delete your own text from the attached returned message.

The Postfix program <x@x.x>: host x.x.x[x.x.x.x] said: 550 5.7.1 Rejected due to Sender-ID policy for sender yyyy@y.y.y (in reply to end of DATA command)

Thanks
Noel

Option to apply best-guess SPF policy

Wed, 14 Mar 2007 23:03:24 -0000

See http://new.openspf.org/FAQ/Best_guess_record

-a list should support IPv6

Nick Sayer — Wed, 21 Jun 2006 16:17:04 -0000

The peer list that is set up with the -a argument should support IPv6
addresses and subnets

e.g.

2002:40a8:47d1::/48

Debug flag: make use of milter-API call smfi_quarantine

Fredrik Pettai — Tue, 30 May 2006 21:08:21 -0000

Today, it can be hard to debug mails, because the mail
that make the milter fail, is rejected or gone. So to
solve that problem and ease debugging, you could create
a new option/flag (for debugging) that takes advantage
of the new milter-API call "smfi_quarantine" (in
sendmail 8.13.X). This debugging flag that should be
passed to the milter at startup, could make the milter
to use the call smfi_quarantine on messages, that for
some reason fails the milters tests. This way, it's
much easier to find out which mail that failed the
milter tests, and why it failed, since you have the
hole messages saved in sendmails quarantine directory.

Add some more \"cause of reject\" messages to SMTP-returncod

Fredrik Pettai — Thu, 25 May 2006 22:22:07 -0000

This RFE is somewhat a compliment to the requested RFEs
1481666 by steve_mckenna.

Then sid-milter are evaulating the SPF/PRA records from
a sender(s domain) and finds out that they are broken
in some way, and sid-milter rejects those mails
(depending on what enforcement policy the SPF/PRA
record has, of course).
Why not reject those mails with SMTP return code +
error message hinting about the broken SPF/PRA record,
for example like "Error(s) found in SPF/PRA policy
during evaluation of....".
This will give the sender a better clue of:
1. Why the mail was rejected.
2. That they have a broken SPF/PRA record in there domain.
(3.) Find libmarid parsing/error-handeling errors :-)

Likewise, it would be extremly helpful to see this
information in the syslogs. (however, if you send this
SMTP error message, it will be show in the "reject=..."
field.

Ignore Responsible Domain and Reject on Failure

schuster11 — Fri, 19 May 2006 18:47:42 -0000

This is a feature request for the ability to reject
emails if they fail the SPF check but to not reject
emails if they do not pass the Responsible Domain check.

So, it would be like enabling the -t flag to not reject
responsible domain but also allow -r 2 to work, where
it would reject emails if the actually fail.

Thanks,
-Dan

syslogging sm_marid_log calls

Steve McKenna — Thu, 04 May 2006 08:00:06 -0000

An enhancement that would be great for tracing plugin
activity, particularly dns lookups, would be to have
an option to syslog all sm_marid_log messages. For
example, adding something like this into sm_marid_log:

sm_marid_log(sm_marid *context, sm_marid_loglevel
level, const char *fmt, ...)
{
va_list va;
char buf[1024];

if (context == NULL || fmt == NULL)
return;

va_start(va, fmt);
vsnprintf(buf, sizeof buf, fmt, va);
va_end(va);

+ if ( sm_marid_logging )
+ {
+ syslog(LOG_DEBUG, "%s", buf );
+ }

(* context->sm_app_log)(context->sm_app_data, level,
buf);
}

turn off syslogging of SMFIS_REJECT

Steve McKenna — Thu, 04 May 2006 07:59:05 -0000

When the logging option has been selected, currently
all SMFIS_REJECT cases are logged. Could we have an
option to turn off the syslogging of SMFIS_REJECT
rejections?

set reply message for no pra

Steve McKenna — Thu, 04 May 2006 07:57:50 -0000

(Optionally?) set a reply message when the responsible
domain cannot be determined. Eg after the line:
/* XXX -- arrange to add a header maybe? */
something like this would be good:
if (!testmode) smfi_setreply(ctx, "550", "5.7.1", "SPF
check can't determine responsible domain" );

Option to specify reject message

Morgan Davis — Thu, 06 Apr 2006 08:39:31 -0000

Please consider adding an option to specify a string
that can override the hard-coded "Rejected due to %s
policy for sender %s" string. The override should
include placeholders that allow insertion of the
following:

* IP address (variable 'ip' exists for this)
* Rejection type ("SPF" or "Sender-ID")
* Bad address (variable 'badaddr' exists for this)

This would allow the sysadmin to specify a rejection
message template such as:

Mail from {ip} rejected due to {sid_check} policy for
sender {sender} - see http://www.openspf.org/why.html?
sender={sender}&ip={ip}

Which might expand to:

Mail from 127.0.0.1 rejected due to SPF policy for
sender foo@bar.com - see
http://www.openspf.org/why.html?
sender=foo@bar.com&ip=127.0.0.1

In addition to giving the sending client a more
useful message, this also gives the sysadmin a single
logfile line to aid in parsing.