Re: delays= a/b/c/d

[Aaron Routt]

Thank you for the honest response. I wish logs and a qshape were available
from my position, but alas, it is not my server, just my problem to solve.

I think the artificial rate delay is the throttling by messagelabs as an
antispam measure. Other outbound mail to various domains is sent and
received with no delay.

If Symantec had more in their document how to whitelist a sender, I could
confirm that has been completed correctly, as no two services use the same
terms in the consol for admins to easily know they are adding a "safe
sender" etc.

Reading this...oi, "you can approve a sender's domain"... no, don't do
that, IP, please. This is what little I can find (Approved Sender)-
https://spammanager-3.messagelabs.com/help.en_US.xsp#2a

But getting answers to my mystery here seemed much more likely than getting
support from Symantec :)

Thanks again, I'll go ask for logs

On Thu, Mar 24, 2016 at 8:58 PM, Viktor Dukhovni  wrote:

>
> > On Mar 24, 2016, at 11:34 PM, Aaron Routt  wrote:
> >
> > The only logs I can access is the receipt-
>
> You'll have to do better than that if you want help.
>
> >
> > Mar 19 19:00:13 mail-d1f9ab60 postfix/smtp[30442]: 3qQpd33djJzDywj:
> to=, relay=cluster1.us.[REDACTED].com[XXX.XX.XX.XXX]:25,
> conn_use=66, delay=193766, delays=193728/38/0/0.1, dsn=2.0.0, status=sent
> (250 ok 1458414013 qp 36488 server-16.tower-192.REDACTED.com
> !1458414005!48124713!66)
>
> You have a backlog of email to this messagelabs hosted domain.  The qshape
> tool might also shed some light on the situation.
> See http://www.postfix.org/QSHAPE_README.html
>
> >
> > Funny thing is the delays started at ~2000+, then after a handful went
> up to 36000+, then after the first 300 deliveries the delay jumps up to
> 18+, which looks like basic throttling to me. I have a hard time
> believing it is my mail sever not sending the mail (though entirely
> possible by the ISP but I've ruled that out), versus their mailserver
> putting it in delayed (you can probably guess the service redacted above).
>
> If the input rate exceeds the output rate for long-enough a backlog forms,
> and "conn_use" numbers become high as Postfix engages demand caching.
>
> >
> > On Thu, Mar 24, 2016 at 8:14 PM, Viktor Dukhovni <
> postfix-us...@dukhovni.org> wrote:
> >
> > > On Mar 24, 2016, at 10:40 PM, Aaron Routt 
> wrote:
> > >
> > > delays=193728/38/0/0.1
> >
> > Insufficient context.  Post all the log entries for the queue-id
> > of the message that logged this combination of delays.
>
> You need to analyze the your logs, there's no silver bullet.
> Understand how quickly mail for this domain is arriving, how quickly
> it is leaving, what your concurrency settings are, any artificial rate
> delays, ...
>
> Skimping on the data you post and/or analyze is a waste of time.
>
> --
> Viktor.
>
>

Re: delays= a/b/c/d

[Viktor Dukhovni]

> On Mar 24, 2016, at 11:34 PM, Aaron Routt  wrote:
> 
> The only logs I can access is the receipt-

You'll have to do better than that if you want help.

> 
> Mar 19 19:00:13 mail-d1f9ab60 postfix/smtp[30442]: 3qQpd33djJzDywj: 
> to=, relay=cluster1.us.[REDACTED].com[XXX.XX.XX.XXX]:25, 
> conn_use=66, delay=193766, delays=193728/38/0/0.1, dsn=2.0.0, status=sent 
> (250 ok 1458414013 qp 36488 
> server-16.tower-192.REDACTED.com!1458414005!48124713!66)

You have a backlog of email to this messagelabs hosted domain.  The qshape
tool might also shed some light on the situation.
See http://www.postfix.org/QSHAPE_README.html

> 
> Funny thing is the delays started at ~2000+, then after a handful went up to 
> 36000+, then after the first 300 deliveries the delay jumps up to 18+, 
> which looks like basic throttling to me. I have a hard time believing it is 
> my mail sever not sending the mail (though entirely possible by the ISP but 
> I've ruled that out), versus their mailserver putting it in delayed (you can 
> probably guess the service redacted above).

If the input rate exceeds the output rate for long-enough a backlog forms,
and "conn_use" numbers become high as Postfix engages demand caching.

> 
> On Thu, Mar 24, 2016 at 8:14 PM, Viktor Dukhovni  
> wrote:
> 
> > On Mar 24, 2016, at 10:40 PM, Aaron Routt  wrote:
> >
> > delays=193728/38/0/0.1
> 
> Insufficient context.  Post all the log entries for the queue-id
> of the message that logged this combination of delays.

You need to analyze the your logs, there's no silver bullet.
Understand how quickly mail for this domain is arriving, how quickly
it is leaving, what your concurrency settings are, any artificial rate
delays, ...

Skimping on the data you post and/or analyze is a waste of time.

-- 
Viktor.

Re: delays= a/b/c/d

[Aaron Routt]

Thank you Viktor,

The only logs I can access is the receipt-

Mar 19 19:00:13 mail-d1f9ab60 postfix/smtp[30442]: 3qQpd33djJzDywj:
to=, relay=cluster1.us.[REDACTED].com[XXX.XX.XX.XXX]:25,
conn_use=66, delay=193766, delays=193728/38/0/0.1, dsn=2.0.0, status=sent
(250 ok 1458414013 qp 36488 server-16.tower-192.REDACTED.com
!1458414005!48124713!66)

Funny thing is the delays started at ~2000+, then after a handful went up
to 36000+, then after the first 300 deliveries the delay jumps up to
18+, which looks like basic throttling to me. I have a hard time
believing it is my mail sever not sending the mail (though entirely
possible by the ISP but I've ruled that out), versus their mailserver
putting it in delayed (you can probably guess the service redacted above).

Many thanks for your assistance


On Thu, Mar 24, 2016 at 8:14 PM, Viktor Dukhovni  wrote:

>
> > On Mar 24, 2016, at 10:40 PM, Aaron Routt  wrote:
> >
> > delays=193728/38/0/0.1
>
> Insufficient context.  Post all the log entries for the queue-id
> of the message that logged this combination of delays.
>
> > http://www.postfix.org/postconf.5.html
> > The format of the "delays=a/b/c/d" logging is as follows:
> >
> >   • a = time from message arrival to last active queue entry
> >   • b = time from last active queue entry to connection setup
> >   • c = time in connection setup, including DNS, EHLO and STARTTLS
> >   • d = time in message transmission
>
> > Does "message arrival" also mean "pickup" in the flowchart? where it
> enters Postfix? My thinking is spam filters are the delay cause here, in
> the "cleanup" process?
>
> Yes, time spent in the "maildrop" directory is included:
>
> On my laptop I used sendmail(1), while Postfix was stopped, and
> then started Postfix:
>
> Mar 24 22:55:08 vpro postfix/postfix-script[88679]:
> starting the Postfix mail system
> Mar 24 22:55:08 vpro postfix/pickup[88682]: 06A07FDE712:
> uid=0 from=
> Mar 24 22:55:08 vpro postfix/cleanup[88684]: 06A07FDE712:
> message-id=<20160325025508.06a07fde...@vpro.lan>
> Mar 24 22:55:08 vpro postfix/qmgr[88683]: 06A07FDE712:
> from=, size=251, nrcpt=1 (queue active)
> Mar 24 22:55:08 vpro postfix/discard[88686]: 06A07FDE712:
> to=, relay=none, delay=12,
> delays=12/0.01/0/0, dsn=2.0.0, status=sent (silently)
> Mar 24 22:55:08 vpro postfix/qmgr[88683]: 06A07FDE712: removed
>
> The 12s delay was due the time it took to type "postfix start" after
> sending the message.
>
> > But a colleague says it is our server sending slowly...but that
> > doesn't make sense..., how is the receiving server going to know
> > of delays by the sending server, if not logged in c/d?
>
> Hard to know without the logs.  Did I mention the logs?  They'll
> show any previous times spent in the active queue, reasons deferred,
> ...  Also find any other queue-ids for the message id and logs for
> those, if any.
>
> --
> Viktor.

Re: delays= a/b/c/d

[Viktor Dukhovni]

> On Mar 24, 2016, at 10:40 PM, Aaron Routt  wrote:
> 
> delays=193728/38/0/0.1

Insufficient context.  Post all the log entries for the queue-id
of the message that logged this combination of delays.

> http://www.postfix.org/postconf.5.html
> The format of the "delays=a/b/c/d" logging is as follows:
> 
>   • a = time from message arrival to last active queue entry
>   • b = time from last active queue entry to connection setup
>   • c = time in connection setup, including DNS, EHLO and STARTTLS
>   • d = time in message transmission

> Does "message arrival" also mean "pickup" in the flowchart? where it enters 
> Postfix? My thinking is spam filters are the delay cause here, in the 
> "cleanup" process?

Yes, time spent in the "maildrop" directory is included:

On my laptop I used sendmail(1), while Postfix was stopped, and
then started Postfix:

Mar 24 22:55:08 vpro postfix/postfix-script[88679]:
starting the Postfix mail system
Mar 24 22:55:08 vpro postfix/pickup[88682]: 06A07FDE712:
uid=0 from=
Mar 24 22:55:08 vpro postfix/cleanup[88684]: 06A07FDE712:
message-id=<20160325025508.06a07fde...@vpro.lan>
Mar 24 22:55:08 vpro postfix/qmgr[88683]: 06A07FDE712:
from=, size=251, nrcpt=1 (queue active)
Mar 24 22:55:08 vpro postfix/discard[88686]: 06A07FDE712:
to=, relay=none, delay=12,
delays=12/0.01/0/0, dsn=2.0.0, status=sent (silently)
Mar 24 22:55:08 vpro postfix/qmgr[88683]: 06A07FDE712: removed

The 12s delay was due the time it took to type "postfix start" after
sending the message.

> But a colleague says it is our server sending slowly...but that
> doesn't make sense..., how is the receiving server going to know
> of delays by the sending server, if not logged in c/d?

Hard to know without the logs.  Did I mention the logs?  They'll
show any previous times spent in the active queue, reasons deferred,
...  Also find any other queue-ids for the message id and logs for
those, if any.

-- 
Viktor.

delays= a/b/c/d

[Aaron Routt]

delays=193728/38/0/0.1

http://www.porcupine.org/postfix/doc/big-picture.html

http://www.postfix.org/postconf.5.html

The format of the "delays=a/b/c/d" logging is as follows:

   - a = time from message arrival to last active queue
    entry
   - b = time from last active queue
    entry to
   connection setup
   - c = time in connection setup, including DNS, EHLO and STARTTLS
   - d = time in message transmission

Does "message arrival" also mean "pickup" in the flowchart? where it enters
Postfix? My thinking is spam filters are the delay cause here, in the
"cleanup" process?

But a colleague says it is our server sending slowly...but that doesn't
make sense..., how is the receiving server going to know of delays by the
sending server, if not logged in c/d?

Thank you in advance

Re: Mail queue free space issue

[Wietse Venema]

Wietse Venema:
> The code in question is 
> 
> double  smtpd_space_multf = 1.5;
> 
> #define BLOCKS(x)   ((x) / fsbuf.block_size)
> 
> if (BLOCKS(var_queue_minfree) >= fsbuf.block_free
>  || BLOCKS(var_message_limit) >= fsbuf.block_free / smtpd_space_multf) {
> (void) smtpd_check_reject(state, MAIL_ERROR_RESOURCE,
...
> The test has two conditions, and one of them is true. In addition
> we know that fsbuf.block_free * fsbuf.block_size = 908328873984
> which is a plausible value (this number is logged in a warning
> message). So both fsbuf.block_free and fsbuf.block_size are
> likely good.
> 
> - If the first condition is true, then the queue_minfree parameter
>   has a small non-zero value. As this is parameter is not read from
>   main.cf, perhaps its compiled-in default value has changed due
>   to a bit-flip in non-ECC memory? A reboot would change that.
> 
> - If the second condition is true, then the message_size_limit
>   parameter has a very large value. As this is read from main.cf
>   and converted to number every time a process starts, a bad
>   bit-flip in the message_size_limit value is unlikely.

In addition we know that the smtpd_space_multf value is good, because
it is logged in a warning message.

My bet is that the queue_minfree variable is corrupted after a
bit-flip. This variable is compile-time initialized, so the value
is read from the smtpd executable file, and my bet is that VM system
keeps much of that file cached in memory.  One bit-flip in some
"data" section can affect all smtpd processes.

Wietse

Re: Mail queue free space issue

[Andy Theuninck]

Sorry, I knew I forgot a detail. I'm running 2.11.0 on Ubuntu 14.04
(their build).

I'm not expecting 10GB emails; that's purely lazy administration on my
part. I'm expecting larger than average attachments, saw some bounces
due to size, and just tacked several zeroes onto the end of the limit.
I'm sure I can fix my own situation by choosing a lower limit. I only
posted to the list in case this is notable or worth doing anything
about.

On Thu, Mar 24, 2016 at 12:14 PM, Bastian Blank
 wrote:
> Hi Andy
>
> On Thu, Mar 24, 2016 at 10:24:16AM -0500, Andy Theuninck wrote:
>> message_size_limit = 1024000
>
> Are you seriously accepting 10GB mails?  This number is larger then
> 2^32.
>
> Bastian
>
> --
> History tends to exaggerate.
> -- Col. Green, "The Savage Curtain", stardate 5906.4

Re: Mail queue free space issue

[Bastian Blank]

Hi Andy

On Thu, Mar 24, 2016 at 10:24:16AM -0500, Andy Theuninck wrote:
> message_size_limit = 1024000

Are you seriously accepting 10GB mails?  This number is larger then
2^32.

Bastian

-- 
History tends to exaggerate.
-- Col. Green, "The Savage Curtain", stardate 5906.4

Re: Mail queue free space issue

[Wietse Venema]

Are you running any particular Postfix version on any particular
platform, built from source or binary distribution?

The code in question is 

double  smtpd_space_multf = 1.5;

#define BLOCKS(x)   ((x) / fsbuf.block_size)

if (BLOCKS(var_queue_minfree) >= fsbuf.block_free
 || BLOCKS(var_message_limit) >= fsbuf.block_free / smtpd_space_multf) {
(void) smtpd_check_reject(state, MAIL_ERROR_RESOURCE,
  452, "4.3.1",
  "Insufficient system storage");
msg_warn("not enough free space in mail queue: %lu bytes < "
 "%g*message size limit",
 (unsigned long) fsbuf.block_free * fsbuf.block_size,
 smtpd_space_multf);

The test has two conditions, and one of them is true. In addition
we know that fsbuf.block_free * fsbuf.block_size = 908328873984
which is a plausible value (this number is logged in a warning
message). So both fsbuf.block_free and fsbuf.block_size are
likely good.

- If the first condition is true, then the queue_minfree parameter
  has a small non-zero value. As this is parameter is not read from
  main.cf, perhaps its compiled-in default value has changed due
  to a bit-flip in non-ECC memory? A reboot would change that.

- If the second condition is true, then the message_size_limit
  parameter has a very large value. As this is read from main.cf
  and converted to number every time a process starts, a bad
  bit-flip in the message_size_limit value is unlikely.

Wietse

Mail queue free space issue

[Andy Theuninck]

I'm seeing a not-enough free space error with the log entry showing
900+ gigabytes in that line. But on a 10/100 network with a couple
seconds at most between the client sending and postfix logging the
error it seems impossible for that much data to have been sent.

This isn't a public email server; I'm scanning documents to email and
using Postfix to pipe them into handler scripts that strip off the
attachments and deliver them into designated directories based on
address. That's why the message size limit is absurdly high.

When I asked on IRC in #postfix they suggested I should email the info
to this list. The guess was a large integer wrap-around issue of some
kind. Logs & postconfs follow:

Logs:
Mar 24 09:32:13 steve postfix/smtpd[30459]: NOQUEUE: reject: MAIL from
unknown[10.2.2.11]: 452 4.3.1 Insufficient system storage; proto=SMTP
helo=
Mar 24 09:32:13 steve postfix/smtpd[30459]: warning: not enough free
space in mail queue: 908328873984 bytes < 1.5*message size limit

postconf -nf:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
message_size_limit = 1024000
mydestination = steve, localhost.localdomain, localhost
myhostname = steve
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 10.2.2.0/24
10.22.22.0/24
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost = [redacted]:submission
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = encrypt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes

postconf -Mf:
smtp inet n - - - - smtpd
pickup unix n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache
maildrop unix - n n - - pipe flags=DRhu
user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp unix - n n - - pipe flags=Fqhu
user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe flags=F user=ftn
argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe flags=Fq.
user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n n - 2 pipe flags=R
user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop}
${user} ${extension}
mailman unix - n n - - pipe flags=FR
user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop}
${user}

SASL with secure password storage

[Benning, Markus]

Hello postfix users,

i'm currently searching for a way to implement SASL authentication with 
postfix

and a secure password mechanism like bcrypt.

sasldb -> plain text
sql -> requires plain text passwords
ldapdb -> requires a ldap server (could use whatever the ldap server 
implements)

saslauthd -> pam, rimap

An ideal solutions for my case would be a local sqlite datebase and 
bcrypt
password storage with the possiblity to migrate to a central sql 
database later.


Suggestions?

 Markus

--
https://markusbenning.de/

Re: postfix sasl auth required

[Wietse Venema]

[plaintext ehlo]
> Im missing my 250-AUTH here
> Or is this because the : "smtpd_tls_auth_only = yes"

Indeed. The SMTP client should protect its password with TLS.
You can check that with:

openssl s_client -starttls smtp -connect host:port

Wietse

postfix sasl auth required

[L . P . H . van Belle]

Hai, 

 

Im testing out my servers and i noticed the following 

 

telnet localhost 587

Trying ::1...

Connected to localhost.

Escape character is '^]'.

220 mail.mydomain.tld ESMTP Ready

ehlo localhost

250-mail.mydomain.tld

250-PIPELINING

250-SIZE 1536

250-VRFY

250-ETRN

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-8BITMIME

250 DSN

 

 

Im missing my 

250-AUTH here after starttls. 

Or is this because the :  "smtpd_tls_auth_only = yes"  

 

I cant figure out what i missed, of if by default if : "smtpd_tls_auth_only = 
yes". Is set no auth is offered? 

And is ETRN needed on the sasl auth?

 

Postfix 2.11.x

 

In having now in master.cf 

submission inet n   -   -   -   -   smtpd

  -o syslog_name=postfix/submission

  -o smtpd_tls_security_level=encrypt

  -o smtpd_sasl_auth_enable=yes

  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

  -o milter_macro_daemon_name=ORIGINATING

 

 

and main.cf

 

smtpd_sasl_auth_enable = yes

smtpd_sasl_path = smtpd

smtpd_sasl_local_domain =

smtpd_sasl_security_options = noanonymous

 

 

 

Greetz, 

 

Louis

 

Re: question re. "wiring in" a mailing list handler

[Wietse Venema]

Miles Fidelman:
> It occurs to me, that right now, mail is passing through the content 
> filters both before it gets to the list manager, and again, after it's 
> exploded by the list manager - creating lots of unnecessary load on the 
> system.
...
> main.cf contains a line:
> content_filter = smtp-amavis:[127.0.0.1]:10024
...
> And then the list manager setup invokes the sendmail compatibility 
> interface to postfix (from the sympa.conf file)

Options:

- Use amavisd configuration to exclude the mailing list sender.

- Configure the Postfix pickup service to skip the content filter.
  master.cf:
pickup .. .. .. .. .. .. pickup -o content_filter=
  Postfix sendmail uses the pick service.

- Configure sympa to submit mail over SMTP to the same poort
  that amavidsd uses to talk to Postfix (or some dedicated service
  that has "content_filter=" in master.cf).

Wietse

pflogsumm patch: SRS unmunging

[Tom Hendrikx]

Hi postfix users,

Ever since I added SRS to my mail setup, reading daily pflogsumm reports
got a lot harder since most senders were changed to SRS addresses. This
also threw off statistics since multiple sender addresses were used when
actually the sender was the same.

Attached is a patch for pflogsumm that unmunges SRS'ed addresses before
using them in the report. Basically I looked at how verp unmunging was
done, and copied that with a regex for SRS. The regex is based on the
SRS format found on Wikipedia and used in the papers in libsrs docs.

@Jim: maybe you could be so kind to include this in the next pflogsumm
version?

Kind regards,
Tom
--- pflogsumm.pl.orig	2016-03-24 11:07:30.806142020 +0100
+++ pflogsumm.pl	2016-03-24 11:36:39.468481189 +0100
@@ -17,7 +17,7 @@
 	[--rej-add-from] [--reject-detail ] [--smtp-detail ]
 	[--smtpd-stats] [--smtpd-warning-detail ]
 	[--syslog-name=string] [-u ] [--verbose-msg-detail]
-	[--verp-mung[=]] [--zero-fill] [file1 [filen]]
+	[--verp-mung[=]] [--srs-mung] [--zero-fill] [file1 [filen]]
 
 pflogsumm.pl -[help|version]
 
@@ -238,6 +238,18 @@
 
 		   See "NOTES" regarding this option.
 
+--srs-mung Undo SRS address munging.
+
+   If your postfix install has an SRS plugin running, many
+   addresses in the report will contain the SRS-formatted
+   email addresses, also for non-local adresses (f.i. 
+   senders). This option will try to undo the "damage".
+
+   Addresses of the form:
+ SRS0=A6cv=PT=sender.example.com=supp...@srs.example.net
+   will be reformatted to their original value:
+ supp...@sender.example.com
+
 --version  Print program name and version and bail out.
 
 --zero-fill"Zero-fill" certain arrays so reports come out with
@@ -496,7 +508,7 @@
 	[--rej-add-from] [--reject-detail ] [--smtp-detail ]
 	[--smtpd-stats] [--smtpd-warning-detail ]
 	[--syslog-name=string] [-u ] [--verbose-msg-detail]
-	[--verp-mung[=]] [--zero-fill] [file1 [filen]]
+	[--verp-mung[=]] [--srs-mung] [--zero-fill] [file1 [filen]]
 
$progName --[version|help]";
 
@@ -538,6 +550,7 @@
 "uucp-mung"=> \$opts{'m'},
 "verbose-msg-detail"   => \$opts{'verbMsgDetail'},
 "verp-mung:i"  => \$opts{'verpMung'},
+"srs-mung" => \$opts{'srsMung'},
 "version"  => \$opts{'version'},
 "zero-fill"=> \$opts{'zeroFill'}
 ) || die "$usageMsg\n";
@@ -795,6 +808,7 @@
 		$addr =~ s/(@.+)/\L$1/ unless($opts{'i'});
 		$addr = lc($addr) if($opts{'i'});
 		$addr = verp_mung($addr);
+		$addr = srs_mung($addr);
 	} else {
 		$addr = "from=<>"
 	}
@@ -1682,6 +1696,7 @@
 if(defined($from)) {
 	$rejAddFrom = $opts{'rejAddFrom'};
 	$from = verp_mung($from);
+	$from = srs_mung($from);
 	$from = lc($from) if($opts{'i'});
 }
 
@@ -1738,6 +1753,16 @@
 }
 
 return $addr;
+}
+
+sub srs_mung {
+my $addr = $_[0];
+
+if(defined($opts{'srsMung'})) {
+$addr =~ s/^SRS(?:[01])(?:[=+-])(?:[^=]+=[\w\.]+==)*(?:[^=]+=[^=]+=)([\w\.]+)=(.+)@[\w\.]+$/$2\@$1/i;
+}
+
+return $addr;
 }
 
 ###


signature.asc
Description: OpenPGP digital signature