smtpctl show queue doesn't show envelope with 451
Hi, With OpenSMTPD 201506112227p1 'smtpctl show queue' doesn't show the queued messages, IIRC this used to work in an older version: # smtpctl show queue But I have two queued messages: # find /var/spool/smtpd/queue/ -type f /var/spool/smtpd/queue/a2/a2c25ab9/message /var/spool/smtpd/queue/a2/a2c25ab9/a2c25ab9900b8de2 /var/spool/smtpd/queue/a2/a2c25ab9/a2c25ab9d701c1c6 # smtpctl show envelope a2c25ab9d701c1c6 version: 2 tag: DKIM type: mta smtpname: mail.etorok.net helo: mail.etorok.net hostname: localhost errorline: 451 4.7.1 Greylisting in action, please come back later sockaddr: 127.0.0.1 sender: rcpt: dest: ctime: 1435129521 last-try: 0 last-bounce: 0 expire: 345600 retry: 2 dsn-notify: 0 esc-class: 4 esc-code: 0 Best regards, --Edwin -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: pki and auth for wildcard certificates
On Wed, Jun 24, 2015 at 11:01:15AM +1000, Jason Tubnor wrote: Hi, Before I go through with purchasing a wildcard cert, can anyone tell me if the following as written in the man page: pki mail.example.com certificate /etc/ssl/mail.example.com.crt pki mail.example.com key /etc/ssl/private/mail.example.com.key listen on lo0 listen on egress tls pki mail.example.com auth --- Would work with a wildcard cert for client authentication? What I'd be looking for is: pki *.mail.example.com certificate /etc/ssl/wildcard.mail.example.com.crt pki *.mail.example.com key /etc/ssl/private/wildcard.mail.example.com.key listen on lo0 listen on egress tls pki *.mail.example.com listen on egress port 587 tls pki *.mail.example.com auth Is the above syntax correct and would it work successfully? Nope, it won't work ... yet. It won't work with our upcoming major release 5.7.1, but if you open a ticket on our tracker, I can fix before the next one. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How to adapt bogus email addresses?
# cat vmap
ilom-alert@192.168.100.63: avantsys...@avant.ca
Looks like there is a colon there -- could that be the problem?
Quoting Adam Thompson athom...@athompso.net:
I'm running smtpd 5.6-RELEASE inside the firewall, acting as an SMTP relay.
One host in particular (a Sun ILOM2 card) inists on sending some
emails addressed to ilom-alert@192.168.100.63. This is a bug in
the firmware that they will not fix, so it's up to me to deal with it.
What I'm trying so far is:
#
# cat smtpd.conf
listen on all
table aliases db:/etc/mail/aliases.db
table vmap db:/etc/mail/vmap.db
table localnets { 192.168.10.0/24, 192.168.100.0/24,
192.168.157.0/24, 192.168.158.0/24, 192.168.101.0/24 }
accept from local for anyrelay via
smtp://smtp-relay.gmail.com
accept from source 192.168.100.63 for any virtual vmap deliver to
lmtp localhost:25
accept from source localnetsfor anyrelay via
smtp://smtp-relay.gmail.com
#
# cat vmap
ilom-alert@192.168.100.63: avantsys...@avant.ca
#
This isn't working, all I get in the log file is:
Jun 24 15:41:06 mailrelay smtpd[18970]: smtp-in: New session
3b402a76adf8e592 from host hexen-ilom.asg.local [192.168.100.63]
Jun 24 15:41:06 mailrelay smtpd[18970]: smtp-in: Failed command on
session 3b402a76adf8e592: RCPT TO:avantsys...@avant.ca = 550
Invalid recipient
Jun 24 15:41:06 mailrelay smtpd[18970]: smtp-in: Closing session
3b402a76adf8e592
...which, ironically, means the ILOM card is NOT misbehaving at the
moment. (Sometimes it does, sometimes it doesn't. Like I said,
it's a bug.)
Why isn't this working?
FYI, the previous log entries for the damaged emails looked like:
Jun 24 15:38:30 mailrelay smtpd[25726]: relay: PermFail for
df4ac3f4da1dd91b: session=9edd2c7aecf6c1b4,
from=ilom-alert@192.168.100.63, to=avantsys...@avant.ca,
rcpt=-, source=192.168.100.96, relay=74.125.142.28
(ie-in-f28.1e100.net), delay=5s, stat=550 5.7.0
https://support.google.com/a/answer/6140680#maildenied
y6sm410732igy.1 - gsmtp
Jun 24 15:38:30 mailrelay smtpd[25726]: smtp-out: Error on session
9edd2c7aecf6c1b4: Connection closed unexpectedly
Jun 24 15:38:31 mailrelay smtpd[25726]: smtp-in: New session
9edd2c7b6ae6b2d7 from host localhost [local]
Jun 24 15:38:31 mailrelay smtpd[25726]: smtp-in: Accepted message
2cdbc169 on session 9edd2c7b6ae6b2d7: from=,
to=ilom-alert@192.168.100.63, size=982, ndest=1, proto=ESMTP
Jun 24 15:38:31 mailrelay smtpd[25726]: smtp-in: Closing session
9edd2c7b6ae6b2d7
Jun 24 15:38:34 mailrelay smtpd[25726]: smtp-out: Connecting to
smtp://74.125.142.28:25 (ie-in-f28.1e100.net) on session
9edd2c7cf3690436...
Jun 24 15:38:34 mailrelay smtpd[25726]: smtp-out: Connected on
session 9edd2c7cf3690436
Jun 24 15:38:34 mailrelay smtpd[25726]: relay: PermFail for
3da7d01d6b54d9ed: session=9edd2c7cf3690436, from=,
to=ilom-alert@192.168.100.63, rcpt=-, source=192.168.100.96,
relay=74.125.142.28 (ie-in-f28.1e100.net), delay=8s, stat=550 5.1.1
https://support.google.com/mail/answer/6596 x14sm419535igx.1 - gsmtp
Jun 24 15:38:34 mailrelay smtpd[9955]: warn: queue: no return path!
Jun 24 15:38:35 mailrelay smtpd[25726]: relay: PermFail for
2cdbc169e9ab3b96: session=9edd2c7cf3690436, from=,
to=ilom-alert@192.168.100.63, rcpt=-, source=192.168.100.96,
relay=74.125.142.28 (ie-in-f28.1e100.net), delay=4s, stat=550 5.1.1
https://support.google.com/mail/answer/6596 x14sm419535igx.1 - gsmtp
Jun 24 15:38:35 mailrelay smtpd[9955]: warn: queue: no return path!
(Naturally, google should reject such badly-addressed emails. That's
what I have to fix before handing it off.)
Thanks,
-Adam Thompson
athom...@athompso.net
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
--
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How to adapt bogus email addresses?
On 06/24/15 16:19, Vijay Sankar wrote:
# cat vmap
ilom-alert@192.168.100.63: avantsys...@avant.ca
Looks like there is a colon there -- could that be the problem?
Quoting Adam Thompson athom...@athompso.net:
I'm running smtpd 5.6-RELEASE inside the firewall, acting as an SMTP
relay.
One host in particular (a Sun ILOM2 card) inists on sending some
emails addressed to ilom-alert@192.168.100.63. This is a bug in
the firmware that they will not fix, so it's up to me to deal with it.
What I'm trying so far is:
#
# cat smtpd.conf
listen on all
table aliases db:/etc/mail/aliases.db
table vmap db:/etc/mail/vmap.db
table suncard { 192.168.100.63 }
table localnets { 192.168.10.0/24, 192.168.100.0/24,
192.168.157.0/24, 192.168.158.0/24, 192.168.101.0/24 }
accept from local for anyrelay via
smtp://smtp-relay.gmail.com
accept from source 192.168.100.63 for any virtual vmap deliver to
lmtp localhost:25
accept from source suncard for any virtual vmap deliver to lmtp
localhost:25
I think you could also just put curly braces like so
accept from source { 192.168.100.63 } etc..., but I'm not sure.
accept from source localnets for anyrelay via
smtp://smtp-relay.gmail.com
#
# cat vmap
ilom-alert@192.168.100.63: avantsys...@avant.ca
#
This isn't working, all I get in the log file is:
Jun 24 15:41:06 mailrelay smtpd[18970]: smtp-in: New session
3b402a76adf8e592 from host hexen-ilom.asg.local [192.168.100.63]
Jun 24 15:41:06 mailrelay smtpd[18970]: smtp-in: Failed command on
session 3b402a76adf8e592: RCPT TO:avantsys...@avant.ca = 550
Invalid recipient
Jun 24 15:41:06 mailrelay smtpd[18970]: smtp-in: Closing session
3b402a76adf8e592
...which, ironically, means the ILOM card is NOT misbehaving at the
moment. (Sometimes it does, sometimes it doesn't. Like I said, it's
a bug.)
Why isn't this working?
FYI, the previous log entries for the damaged emails looked like:
Jun 24 15:38:30 mailrelay smtpd[25726]: relay: PermFail for
df4ac3f4da1dd91b: session=9edd2c7aecf6c1b4,
from=ilom-alert@192.168.100.63, to=avantsys...@avant.ca,
rcpt=-, source=192.168.100.96, relay=74.125.142.28
(ie-in-f28.1e100.net), delay=5s, stat=550 5.7.0
https://support.google.com/a/answer/6140680#maildenied
y6sm410732igy.1 - gsmtp
Jun 24 15:38:30 mailrelay smtpd[25726]: smtp-out: Error on session
9edd2c7aecf6c1b4: Connection closed unexpectedly
Jun 24 15:38:31 mailrelay smtpd[25726]: smtp-in: New session
9edd2c7b6ae6b2d7 from host localhost [local]
Jun 24 15:38:31 mailrelay smtpd[25726]: smtp-in: Accepted message
2cdbc169 on session 9edd2c7b6ae6b2d7: from=,
to=ilom-alert@192.168.100.63, size=982, ndest=1, proto=ESMTP
Jun 24 15:38:31 mailrelay smtpd[25726]: smtp-in: Closing session
9edd2c7b6ae6b2d7
Jun 24 15:38:34 mailrelay smtpd[25726]: smtp-out: Connecting to
smtp://74.125.142.28:25 (ie-in-f28.1e100.net) on session
9edd2c7cf3690436...
Jun 24 15:38:34 mailrelay smtpd[25726]: smtp-out: Connected on
session 9edd2c7cf3690436
Jun 24 15:38:34 mailrelay smtpd[25726]: relay: PermFail for
3da7d01d6b54d9ed: session=9edd2c7cf3690436, from=,
to=ilom-alert@192.168.100.63, rcpt=-, source=192.168.100.96,
relay=74.125.142.28 (ie-in-f28.1e100.net), delay=8s, stat=550 5.1.1
https://support.google.com/mail/answer/6596 x14sm419535igx.1 - gsmtp
Jun 24 15:38:34 mailrelay smtpd[9955]: warn: queue: no return path!
Jun 24 15:38:35 mailrelay smtpd[25726]: relay: PermFail for
2cdbc169e9ab3b96: session=9edd2c7cf3690436, from=,
to=ilom-alert@192.168.100.63, rcpt=-, source=192.168.100.96,
relay=74.125.142.28 (ie-in-f28.1e100.net), delay=4s, stat=550 5.1.1
https://support.google.com/mail/answer/6596 x14sm419535igx.1 - gsmtp
Jun 24 15:38:35 mailrelay smtpd[9955]: warn: queue: no return path!
(Naturally, google should reject such badly-addressed emails. That's
what I have to fix before handing it off.)
Thanks,
-Adam Thompson
athom...@athompso.net
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How to adapt bogus email addresses?
On 06/24/2015 04:19 PM, Vijay Sankar wrote: # cat vmap ilom-alert@192.168.100.63: avantsys...@avant.ca Looks like there is a colon there -- could that be the problem? Not according to the makemap(8) manpage: The database key and value may optionally be separated by the colon character. The documentation on virtual domains is spotty enough that I might be invoking makemap wrong, or misinterpreting what it can do altogether... -Adam
